Active probes

Weekly load-probe to catch silent breakages.

Anomaly alerts watch the events that are firing. Active probes catch the opposite failure: a page that has quietly stopped loading your tracking at all — a GTM republish that dropped the Monitor tag, a CMS deploy that broke the container, a consent banner that now blocks everything. A probe loads your site in a real headless browser on a schedule and checks the tracking is actually there, even when no visitor has fired an event.

What a probe checks

For each monitored signal, the probe loads the page in a headless Chrome and verifies the two things that have to be true for monitoring to work:

  • GTM present — your Google Tag Manager container is on the page.
  • dataLayer ready — the dataLayer array exists, so the Monitor tag has something to push into.

A run that finds both passes. A run that's missing either — or that can't load the page — fails. The probe records what it saw (gtmPresent, dataLayerArray, the final URL after redirects) so a failure is diagnosable, not just a red flag.

Schedule & the 3-strike rule

  • A scheduler queues one probe per monitored signal (domain · scenario · channel) and spaces runs about a week apart — enough to catch a breakage within days without hammering your site.
  • A single failure does not alert. Headless loads are occasionally flaky (a slow third-party script, a transient 503), and we won't page you for noise.
  • After 3 consecutive failures, the probe raises a probe_failed alert at critical severity — see Anomaly alerts.
  • The next time the probe passes, it auto-resolves its own alert. You don't have to clear it by hand.

ℹ Probes own their alerts

A probe_failed alert is managed entirely by the probe runner, not the nightly anomaly sweep. The anomaly cron will never auto-resolve a probe alert — only a passing probe does. This keeps the two systems from stepping on each other.

Why a probe and not just "no_activity"?

The no_activity anomaly alert also catches a dead scenario — but only after a scenario that normally fires goes silent for a day, and only for scenarios with an established baseline. A probe is proactive and baseline-free: it tells you the tracking is physically gone before a campaign weekend burns a day of data, and it works on a low-traffic page that might not fire any event in 24 hours at all.

Common questions

Will the probe inflate my counts or my Visits? No. The probe loads the page headlessly to inspect it; it doesn't fire your tracked events, and its own user-agent is filtered out of the Visits count by the bot filter.

My probe failed once then passed — did I miss an alert? No alert is raised on a single (or double) failure. The strike counter only trips at 3 in a row, and a pass resets it. A lone transient failure is expected and harmless.

Does this work on pages behind a login? Not today — the probe loads the public URL anonymously. For authenticated funnels, rely on event monitoring + no_activity alerts instead.

Probes are the "is the smoke detector still on the ceiling?" check; anomaly alerts are the "is there smoke?" check. You want both — one catches silent removal, the other catches live drops.