When to use this
Runtime verification is Step 6 of setup and should run after your consent banner is published and every other required step for your plan is complete. On Pro that includes Legal Pages (Step 5); on Growth that also includes Tracker Blocking (Step 4). Unlike install verification, this pass validates the entire protection stack working together on production: the script boots, published configuration loads, the banner UI mounts, a fresh setup heartbeat arrives, and on Growth the blocking engine reports active enforcement.
Open the Runtime Verification page from Setup or your site’s runtime-verification route when you are preparing to go live or when Protection view shows degraded health. The dashboard surfaces status cards for script, config, UI, heartbeat age, and blocking so you can see which signal failed without reading raw logs.
Pro and Growth plans include heartbeat and owner diagnostics; Free plans do not run managed runtime verification because they lack managed sites. If any check fails, fix the underlying issue before activating Go Live—partial protection can leave trackers firing pre-consent.
Step-by-step instructions
- Confirm required prior steps are complete: on Pro, Steps 1, 2, 3, and 5 (connect site, install, banner publish, legal pages); on Growth, Steps 1–5 (including tracker blocking and legal pages).
- Open Setup → Step 6 · Runtime Verification or the site-specific runtime verification panel.
- In a private browser window, load your homepage and dismiss or accept the banner once to exercise UI mount.
- Trigger a fresh visit—navigate to a second page if your SPA requires it for heartbeat emission.
- Click Run verification or Refresh in the dashboard to pull the latest health snapshot.
- Review each status card: Script, Runtime boot, Config loaded, UI rendered, Heartbeat, Blocking engine.
- If heartbeat is stale, revisit install placement and ad-blocker-free testing per Verify installation help.
- If blocking fails on Growth, open Tracker Blocking and confirm enforcement mode is saved and published config synced.
- When all checks pass, the panel shows a success summary and Step 6 marks complete—proceed to Step 7 · Go Live.
Expected result
All runtime verification checks pass simultaneously. The UI summary states that runtime, config, banner, heartbeat, and enforcement are healthy. Step 6 in the wizard shows completed, unlocking Step 7 · Go Live. Runtime Health elsewhere in the dashboard should show success indicators (brand cyan) on healthy cards; setup-in-progress states use neutral gray, and only real failures use red.
You now have evidence—not just configuration—that visitors receive enforced consent behavior. Keep a screenshot or export diagnostics if compliance stakeholders ask for proof.
Troubleshooting
Heartbeat received but blocking not checked
On Growth, save tracker enforcement settings and republish consent config if you changed categories. Load a page that would normally fire analytics before consent; the engine must observe blockable requests. Growth users can open tracker blocking debug to see per-domain decisions. Pro does not include the tracker blocking setup step—blocking checks in verification reflect runtime capabilities for your plan.
Config loaded false
Publish the consent banner from the CMP editor—draft-only config does not ship to the runtime. Check for API errors on publish and confirm site id in the script matches the site you edited. CDN caches rarely affect JSON config fetches but corporate proxies might—test outside VPN.
UI rendered false
Ensure banner is enabled in published settings and not restricted to a geography you are not testing from. CSS z-index conflicts can hide the banner while still failing UI mount detection—inspect shadow DOM or overlay elements in DevTools.