Runtime diagnostics for site owners

When to use this

Runtime diagnostics are available on managed Pro and Growth sites after install. They expose data public scans cannot: last heartbeat time, config version loaded, blocking engine state, blocked request counts, and setup heartbeat freshness bands. Use them when verification fails intermittently, when Protection shows warn tones, or when marketing reports a tracker still firing.

Owner diagnostics are private operational signals—not shared with visitors. They complement compliance scores by showing what your runtime actually did in the last few minutes.

Growth adds deeper tracker blocking debug panels and consent replay verification hooks; Pro still receives runtime health dashboard and baseline telemetry.

Heartbeat freshness bands classify how recent setup telemetry is—stale bands during business hours usually mean no organic traffic or a removed script, not a GDPRChecker outage. Compare lastHeartbeatAt with your analytics traffic charts.

When filing support tickets, include site id, approximate visit time in UTC, browser used for test, and whether consent was accepted—diagnostics without visitor action can look falsely idle.

Spikes in blocked counts after campaigns are normal; sustained zero blocking with heavy traffic suggests enforcement regression worth incident review.

Mobile Safari private mode tests are valuable because ITP and blockers change heartbeat reliability—note browser in tickets.

Step-by-step instructions

1. Open Dashboard → Protection or Runtime Health for your active site.
2. Check connection status: online, degraded, or offline based on heartbeat age.
3. Compare script detected vs runtime booted flags—divergence implies JS errors before boot completes.
4. Note config version or published timestamp and confirm it matches your last publish.
5. Review blocked requests counter after a test visit without marketing consent.
6. Open advanced diagnostics or tracker blocking debug on Growth if enabled.
7. Cross-check public scan at /scanner for the same URL to spot public/private drift.
8. File engineering tickets with timestamps, site id, and screenshot of status cards.
9. After fixes, trigger a fresh visit and confirm heartbeat band returns to fresh.
10. Compare config version on diagnostics panel with published timestamp in consent summary.
11. Subscribe to internal status communications if GDPRChecker announces platform incidents affecting heartbeat ingestion.
12. Re-run verification after platform incidents clear.

Expected result

You identify whether issues are install, config, UI, heartbeat, or blocking class without guessing. Healthy status cards show success indicators (brand cyan); setup-in-progress states use neutral gray; only failures use red. Public scan rescans optionally confirm external view improved.

Ongoing monitoring catches CDN regressions that remove the script tag days after go live.

During incidents, capture status card screenshot before and after fix—support can correlate config version and heartbeat timestamps faster with visuals than prose alone.

Troubleshooting