> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Traffic Drop Alert, Google Analytics 4 > Catches DNS / GTM / CDN / SEO-de-index events before any other dashboard does. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Analytics](/nerve-centre/connectors#connectors-by-type) > 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. | | | | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `(GA4 sessions in trailing 1h) ÷ (median GA4 sessions for the same hour-of-day & day-of-week across prior 7 weeks)`, expressed as a percentage. Fires when the ratio drops below 0.75 (i.e. 25% below baseline). | | **Sample basis** | Sessions, the broadest top-of-funnel signal. Sessions drop *before* purchases drop in nearly every site-wide regression scenario, which is why this alert leads the pack. | | **Sampling threshold** | None for the 1h × DOW dimension. The query is a metric-only `runReport` over a 1-hour window; never sampled. | | **Bot traffic filter** | GA4's built-in IAB Tech Lab bot filter applied. **Bot waves can briefly inflate sessions and mask a real drop** (e.g. an 80% real-user drop concurrent with a 60% bot wave looks like a 20% drop). Pair with [GA4 Bot Traffic Share](/nerve-centre/kpi-cards/google-analytics/bot-traffic-share) to disambiguate. | | **Time zone** | The GA4 property's timezone, NOT UTC. The DOW/hour-of-day baseline is anchored to property zone so an alert at "Tuesday 14:00" uses Tuesday-14:00 from prior weeks. | | **Currency** | Not applicable, this card uses session counts, not revenue. | | **Refunds** | Not applicable. | | **Tracking-gap framing** | The structural GA4 tracking gap (10, 25%) affects sessions less than purchase events because the failure mode is different: sessions are recorded on any pageview, while purchases require the order-confirmation page to load successfully. **A traffic-drop alert is therefore a relatively pure signal of real traffic loss, not a measurement artefact.** Exception: GTM container delete = sessions go to zero; that's both a measurement failure AND a real "we can't see traffic" event. | | **Why 7-day baseline, not 30-day?** | A 7-day baseline catches week-over-week patterns (Tuesday looks like last Tuesday). A 30-day baseline would smooth seasonal trends but lag on detecting acute changes. 7 days is the sweet spot for fire-alarm alerts. | | **Time window** | `RT` (real-time, refreshed every 15 minutes; the trailing 1h is the alert window). | | **Alert trigger** | `drop >25% vs prior 7-day same-DOW window`, sentiment\_key `ga_traffic_trend`. The 25% threshold is calibrated to suppress normal hourly noise (typical hour-to-hour variance is 5, 15%) while catching real regressions early. | | **Roles** | owner, marketing | ## 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. | Hour (BST) | Sessions (this Wed) | Median sessions (prior 7 Wednesdays, same hour) | Ratio | Status | | ------------ | ------------------- | ----------------------------------------------- | ----- | ------------------------------- | | 09:00, 10:00 | 412 | 396 | 1.04× | Normal | | 10:00, 11:00 | 287 | 432 | 0.66× | **Alert: drop 34% vs baseline** | | 11:00, 12:00 | 142 | 451 | 0.31× | Alert continues, getting worse | | 12:00, 13:00 | 89 | 478 | 0.19× | Alert continues, severe | 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](/nerve-centre/kpi-cards/google-analytics/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 | Card | Why pair it with Traffic Drop Alert | | ----------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [GA4 Sessions](/nerve-centre/kpi-cards/google-analytics/sessions) | The metric this alert is built on. Use to see the trend over a wider window. | | [GA4 Real-Time Active Users](/nerve-centre/kpi-cards/google-analytics/real-time-active-users) | The 30-min companion. If this card alerts AND active users is zero or near-zero, the site is fully unreachable. | | [GA4 Property Health](/nerve-centre/kpi-cards/google-analytics/ga4-property-health) | The composite measurement-health view. If Property Health is also amber/red, the "drop" may be a measurement regression (GTM broken) rather than a traffic loss. | | [GA4 Bot Traffic Share](/nerve-centre/kpi-cards/google-analytics/bot-traffic-share) | The disambiguator. Real-user drop concurrent with bot wave can look like "no drop"; bot share data tells you what's actually happening. | | [GA4 Conversion Rate](/nerve-centre/kpi-cards/google-analytics/ecommerce-conversion-rate) | The downstream impact. If this alert fires AND CR holds steady, the remaining traffic is converting normally; if CR also drops, the regression is broader than just traffic. | | [GA4 Revenue Trend](/nerve-centre/kpi-cards/google-analytics/revenue-trend) | The lagging-indicator validation. Revenue Trend will dip \~1, 4 hours after this card alerts (purchase events follow session loss). | | [Cross-platform: Revenue at Risk from Incident](/nerve-centre/kpi-cards/google-analytics/revenue-at-risk) | If a monitoring-platform incident is open concurrent with this alert, the two corroborate. | | [Cross-platform: Traffic to Revenue Divergence](/nerve-centre/kpi-cards/google-analytics/traffic-to-revenue-divergence) | The 30D companion for measurement-vs-truth divergence. | ## 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](https://analytics.google.com/)** 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):** | Reason | Direction of divergence | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | **Polling lag**. We refresh every 15 minutes. A regression at 14:30 may not surface until 14:45. | 0, 15 min lag | | **Baseline anomaly suppression**. If the prior 7-day window had a >2σ outlier (viral moment, holiday, planned campaign), we flag the alert as low-confidence and don't auto-page. | Variable | | **Maintenance windows**. Configured maintenance windows suppress alerts; the card displays "in maintenance" in lieu of an alert. | Suppressed alerts during configured windows | | **Sessions vs active users**. We use sessions; GA4's Realtime Overview uses active users. The two correlate but aren't identical (one user can have multiple sessions in an hour; sessions count higher). | Sessions count typically 1.05, 1.20× higher than active users | **Cross-connector reconciliation, the IMPORTANT one:** This is a GA4-only alert at the technical level, but it correlates strongly with cross-connector signals: | Card | Expected relationship | What divergences mean | | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`shopify.total_revenue`](/nerve-centre/kpi-cards/shopify/total-revenue) | Revenue typically follows sessions with a 30, 90 minute lag. A traffic-drop alert is followed by a revenue dip \~1h later. | Revenue dipping WITHOUT a traffic-drop alert = checkout/CR regression (different problem). | | [`bigcommerce.total_revenue`](/nerve-centre/kpi-cards/bigcommerce/total-revenue) | Same shape. | Same. | | [`adobe_commerce.total_revenue`](/nerve-centre/kpi-cards/adobe-commerce/total-revenue) | Same shape. | Same. | | [`datadog.datadog_incidents`](/nerve-centre/datadog/datadog_incidents) | If Datadog has an open incident concurrent with this alert, the two are likely the same root cause (DNS, CDN, infrastructure). | A traffic-drop alert WITHOUT a Datadog incident = the regression isn't infrastructure-monitored (e.g. SEO de-index, paid-ad-account suspension, third-party tag block). | | [`google_search_console.organic_clicks`](/nerve-centre/google_search_console/organic_clicks) | If the drop is SEO-driven, Search Console will show a concurrent click drop and possibly index-coverage warnings. | The fastest way to confirm an SEO-cause traffic drop. | **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](/nerve-centre/kpi-cards/google-analytics/ecommerce-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](/nerve-centre/kpi-cards/google-analytics/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](/nerve-centre/kpi-cards/google-analytics/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](/nerve-centre/kpi-cards/google-analytics/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.