Skip to main content
Metrics type: Key Metrics • Category: Analytics
Catches DNS / GTM / CDN / SEO-de-index events before any other dashboard does.

​
At a glance

A real-time alert that fires when GA4 sessions for the trailing hour drop >25% vs the same hour-of-day on the same day-of-week from the prior 7-day window. Designed to catch DNS, GTM, CDN, and SEO-de-index events within minutes, hours before any revenue-side card visibly degrades. The card is a fire-alarm bell, not a measurement.

​
Calculation

Calculated automatically from your Google Analytics 4 data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

​
Worked example

A UK gardening retailer on Shopify, GA4 connected. Property timezone Europe/London. On 06 May 26 at 11:00 BST (a Wednesday), the alert fires. Three numbered observations:
  1. The alert fired at 10:00, 11:00, 13 minutes after the regression started. Detection latency: GA4 has up to 4-hour event-ingestion delay for batched reports, but the runReport API for the trailing-hour window typically lags 5, 15 minutes. The alert detector’s 15-minute polling cycle adds another 0, 15 min. Total detection latency: 10, 30 minutes from a real traffic stop. That’s hours faster than waiting for revenue cards to dip; the merchant gets a head start on triage.
  2. Triage workflow when this card fires. Order of investigation: (a) is the site reachable? Curl the homepage from a non-merchant IP. If 5xx, escalate to engineering; (b) is GA4 receiving events? Check Realtime → Events; if zero, the GTM container or GA4 measurement ID has been broken; (c) is Google Search Console showing crawl errors or de-indexing? Check Search Console → Coverage; (d) is your CDN healthy? Check Cloudflare/Fastly/Akamai dashboard for upstream errors; (e) is your DNS resolving? dig yourdomain.com from multiple regions; (f) is paid traffic still flowing? Check Google Ads/Meta Ads dashboards for “running” status.
  3. For this brand, the cause was a Shopify-side DNS regression. The brand’s apex domain gardenshop.co.uk had a custom CNAME that was accidentally removed during a DNS migration; users hitting gardenshop.co.uk got NXDOMAIN, while www.gardenshop.co.uk still worked. Most users (~70%) hit the apex first; only the www-aware bookmark crowd kept reaching the site. The 34% baseline retained = www. users + paid-ad direct-link users. The card detected this within 30 minutes; without it, the merchant would have noticed via revenue cards 4, 6 hours later.
  4. What WOULD trip false positives? Three known patterns: (a) a planned site maintenance window (Sunday 3am, scheduled deploys); we suppress alerts during configured maintenance windows. (b) a public holiday that the 7-day baseline doesn’t account for (Boxing Day, Thanksgiving), the alert fires for “low traffic” that’s actually normal-for-holiday. (c) a viral PR moment the previous week that inflated the baseline, this week looks low by comparison. The card surfaces a “baseline anomaly” warning when the prior 7-day window has a >2σ outlier.
  5. Bot waves can mask the drop. If a bot scraping campaign is concurrent with a real traffic drop, sessions may appear steady while real users are gone. Cross-check GA4 Bot Traffic Share: if bot share suddenly spiked, real-user sessions are dropping more than this card shows.
Rule of thumb. Alert fires = drop everything and check site reachability. Even a false positive is worth 5 minutes of investigation, the cost of missing a real DNS/CDN regression is hours of lost revenue.

​
Sibling cards merchants should reference together

​
Reconciling against the vendor’s own dashboard

Where to look in GA4: GA4 doesn’t have a native “trailing-1h vs same-DOW-baseline” alert (its Custom Insights are limited and slow). The closest GA4-native rebuild:
Realtime → Overview → Users by minute for the live signal. Compare the current 30-min count against the 30-min average GA4 displays. Reports → Realtime → Sessions by source to see if the drop is concentrated in one channel (bad PPC campaign, lost organic ranking) or across all channels (DNS, CDN, GTM-level).
Other GA4 views that look like real-time traffic monitoring but aren’t:
  • Reports → Acquisition (any view): 24h+ lag; useless for real-time alerting.
  • GA4 Custom Insights: GA4’s own alert system. Slower polling (typically 24h), no DOW-aware baselining, can’t easily configure 1-hour windows.
  • DebugView: per-session debugging; not aggregate counts.
Why our alert may legitimately differ from a manual check (rare): Cross-connector reconciliation, the IMPORTANT one: This is a GA4-only alert at the technical level, but it correlates strongly with cross-connector signals: This card is not the source of truth for site-uptime, your monitoring platform is. This card uses customer-side traffic data to detect what monitoring platforms can miss (DNS-level outages that bypass your synthetic checks, regional CDN issues your monitoring doesn’t probe from, SEO de-indexing that has nothing to do with infrastructure).

​
Known limitations / merchant FAQs

The alert fired but my Datadog/New Relic dashboard says everything is healthy. Is the alert wrong? Probably not. Monitoring platforms detect problems they’re configured to detect (synthetic checks, error rates, latency); they miss problems they’re not configured for. Common scenarios where this card alerts and Datadog doesn’t: (a) DNS-level outage (your synthetic check IPs may resolve fine while public-internet DNS doesn’t), (b) regional CDN degradation that affects users but not your monitoring vantage points, (c) SEO de-indexing (Google removed your site from rankings; nothing infrastructure-y is broken), (d) third-party tag-blocker rollout (uBlock Origin, browsers’ enhanced tracking protection) blocking GA4 specifically. The card complements monitoring; it doesn’t duplicate it. How fast does this alert fire? Detection latency is 10, 30 minutes from a real traffic stop: 5, 15min for GA4 to ingest events, 0, 15min for the polling cycle. That’s fast enough to catch most outages within their first half hour, hours before revenue cards visibly drop. For sub-5-minute detection, use synthetic monitors in Datadog/New Relic; this card is for the events those synthetics miss. Why didn’t the alert fire? My Shopify revenue dropped 40% but the card stayed green. Two possibilities: (1) the revenue drop is a checkout regression, not a traffic regression. Sessions are healthy; conversions aren’t. Use GA4 Conversion Rate instead, or (2) the drop is concentrated in one channel (e.g. paid social campaign turned off) but other channels grew, leaving total sessions stable. Use GA4 Sessions by Channel for a per-channel view. What happens during a planned maintenance window? The alert is suppressed during configured maintenance windows (configured per-property in Vortex IQ settings). The card shows “in maintenance” rather than firing. Don’t forget to remove the maintenance flag after the window; if you forget and a real outage happens, the alert won’t fire. My traffic dropped 20%, just below the alert threshold. Should I be worried? Not necessarily, hour-to-hour variance of 5, 20% is normal noise. But persistent borderline-low traffic (e.g. 4 hours in a row 18, 22% below baseline) is suspicious; this card has a “trending low” amber state that triggers at sustained 15% drop without firing the page-the-on-call hard alert. Why do you use a 7-day baseline instead of 30-day? A 7-day baseline catches week-over-week patterns precisely (this Tuesday vs the average of the last 7 Tuesdays). A 30-day baseline smooths seasonality but lags acute changes. The 7-day window is the sweet spot for fire-alarm alerts, fast enough to catch real regressions, slow enough to absorb daily noise. Trended cards (Revenue Trend, Sessions Trend) use 30D; alert cards use 7D. My alert keeps firing every Sunday at 3am. Is something wrong? Probably not. Sundays at 3am are typically very low-traffic periods; if you have a viral moment any other Sunday-3am in the prior 7 weeks, the baseline gets inflated, and the next Sunday-3am looks low by comparison. The card surfaces a “baseline anomaly” warning when the prior 7-day window has high variance; if you see that warning persistently, raise the alert threshold for that hour-of-week or add a weekly-recurring maintenance window. Bot waves are masking my traffic drop. What can I do? Pair this card with GA4 Bot Traffic Share. When bot share spikes, total sessions can stay flat while real-user sessions drop. The card’s drill-down shows a “bot-adjusted” sessions count: total sessions − estimated-bot sessions. Use that for true real-user trending during bot-affected periods. Does this alert work for new GA4 properties? Properties under 7 days old don’t have a stable DOW baseline. We use a flatter aggregate (median of all hours in the prior 7 days) and flag the alert as low-confidence for the first week. After 7 days, full DOW-aware alerting kicks in. Will this alert fire during a planned ad campaign that brings extra traffic? No, this card alerts on drops, not spikes. A traffic spike from a campaign is healthy; the card stays green and the spike shows as a positive deviation. (Spikes are tracked by GA4 Traffic Trend, which has its own anomaly detection for unusual peaks.)

​
Tracked live in Vortex IQ Nerve Centre

Traffic Drop Alert is one of hundreds of KPI pulses Vortex IQ tracks across Google Analytics 4 and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. Start for free or book a demo to see this metric running on your own data.