Why GA4's built-in alerts won't tell you when tracking breaks
GA4 ships with custom insights and anomaly detection, so it's natural to assume you're covered. But both features analyze the data that arrives — and when tracking breaks, the defining symptom is that data stops arriving.
6 min read
The core blind spot
GA4 is an analytics system, not a monitoring system. Everything it knows comes from the hits your site sends it. When a tag is removed in a deploy, blocked by a CSP header, or orphaned by a renamed trigger, GA4 doesn't register an error — it registers nothing, which is indistinguishable from a quiet day.
To GA4, "your checkout tracking died" and "nobody bought anything this morning" look identical. A monitoring system needs an independent signal — the events actually firing on your pages, or a second platform to compare against — to tell those apart.
Four specific gaps in GA4's alerting
These aren't bugs — they're consequences of what the features were designed to do.
Detection latency is measured in days, not minutes
Custom insights mostly evaluate daily (hourly exists only for web streams, with restrictions). A purchase tag that breaks Monday morning produces, at best, an email Tuesday. For a store spending meaningfully on ads, that's a full day of optimization running on wrong signals plus a day of lost conversion data that never comes back.
Zero-data conditions are second-class
You can write an insight for "purchases = 0 today," but you'd need one per critical event, each evaluated on the daily cycle, each unable to say whether zero is a tracking failure or a genuinely quiet period. Nobody maintains this at the per-event level in practice.
Anomaly detection misses partial breaks
Statistical anomaly detection needs the break to be large and sudden relative to normal variance. The common real-world failure — tracking dies on one page template, one browser family, or one consent segment — shifts totals by 10–30%, which sits comfortably inside the expected band for weeks.
Notifications are best-effort emails
Insight notifications go to email only — no Slack, no webhook, no escalation — and delivery reliability is a recurring community complaint. An alerting system you don't fully trust gets checked manually, which means it isn't really an alerting system.
What closes the gap
An independent observation point
Monitoring has to watch the events firing on the site itself, upstream of GA4's pipeline. Then "the tag stopped sending" is directly observable rather than inferred from an absence in reports.
A learned baseline per event
Every event has a rhythm — purchases hourly, page views constantly, sign-ups in bursts. Detection should compare against each event's own history, so an event that normally fires every few minutes going silent for an hour is an incident, not a statistical footnote.
Cross-platform comparison
The strongest broken-vs-quiet signal: if Meta Pixel keeps reporting purchases while GA4 shows none, that's not a slow morning — that's a broken GA4 tag. Single-platform tools structurally can't make this comparison.
Minutes-level alerting with recovery
Alerts should reach where your team works (Slack, email), arrive within minutes, and resolve themselves when the event recovers — so they stay trusted instead of muted.
Where Kickin fits
Kickin is that independent observation layer. One script tag watches your GA4, Meta Pixel, and Google Ads events as they fire, learns each event's normal pattern, and opens an incident when an event stops, its parameters drift, or platforms fall out of sync — with alerts in minutes, not days.
Keep your GA4 custom insights for business questions — "did conversion rate drop?" is a fine daily email. Use dedicated monitoring for the question GA4 can't answer about itself: "is my tracking still working right now?"
Related: Audit vs. monitoring · Did a deploy break your tracking? · GA4 event monitoring
FAQ