Can Google Analytics Tell You When Your Website Is Down? The Honest Answer
Google Analytics cannot tell you that your website is down. It can show you that data stopped arriving, which is a different statement, and it usually shows you that hours after the fact. The reason is structural rather than a missing feature: GA only ever learns about pages that successfully loaded and successfully ran its tag.
This article explains why that architecture makes outage detection impossible in principle, what GA can genuinely contribute during an incident, how far its anomaly alerting can be pushed and where it stops, and what to pair it with so that the gap is covered. It also covers the specific ambiguity that makes an analytics-based alert dangerous even when it does fire, which is that a flat line has more than one cause.
Why the tag cannot report on a page that never loaded
Google Analytics is client-side. A visitor requests a page, your server returns it, the browser parses it, the GA snippet executes, and only then does a request travel to Google's collection endpoint carrying the event. Every step in that chain has to succeed before Google learns anything at all.
Now remove the first step. Your server is returning 503, or refusing connections, or timing out, or failing DNS resolution. The browser never receives a page, so the tag never executes, so no request reaches Google. From Google's point of view nothing happened. There is no error event, no failure signal, and no distinction between an outage and a quiet Tuesday. The absence of data is the only trace, and absence has no timestamp of its own.
This is why the question has a clean structural answer rather than a feature answer. Asking GA to detect downtime is asking a system that only hears from working pages to report on pages that did not work. No configuration fixes that, because the information was never transmitted. It matters most during partial outages, where a fine homepage in front of a checkout throwing 500s still produces a healthy-looking traffic line.
What Google Analytics can actually contribute
None of that makes GA useless during an incident. It is genuinely good at two things that monitoring is not.
The first is scope. Once you know something is wrong, GA can tell you who is affected, because its dimensional data survives the parts of the site that still work. Traffic holding steady on desktop and collapsing on mobile, or holding in one country and collapsing in another, narrows the search considerably. Our post on why a site can be down on mobile but not desktop covers the specific causes that pattern points to.
The second is business impact. Monitoring tells you a checkout endpoint returned errors for forty minutes. GA tells you what forty minutes of that page normally produces in sessions and conversions, which is the number that reaches the incident review. Reaching for GA at that stage is correct. Reaching for it to learn an incident started is not.
The anomaly alerting question, and where it stops
GA4 does support alerting on unusual patterns through custom insights, and it is reasonable to ask whether that closes the gap. It does not, for two reasons that are worth being precise about.
The first is cadence, and it is better than most people assume. Custom insights can be evaluated hourly, not only daily, though Google notes that hourly evaluation is available for web data and not for app events. An hour is a real improvement on a day. It is still an hour, which means a forty minute outage can start and finish without a single evaluation running, and the fastest possible notification still arrives up to sixty minutes after the problem began. Anomaly detection adds its own lead time on top, because the model needs history before it produces anything useful, roughly two weeks of data for hourly evaluation and ninety days for daily.
The second is ambiguity, and it is the more important one. A GA alert that fires on a traffic collapse cannot tell you whether the site went down or the tag stopped firing. Those two causes produce an identical flat line, and they call for completely different responses. Someone paged by an analytics alert at midnight has to first determine whether there is an incident at all, which is the opposite of what an alert should do. The analytics traffic drop question deserves its own treatment for exactly this reason.
So the honest positioning is that GA anomaly alerts are a useful backstop for slow-burning problems, such as a tag broken by a deploy three days ago that nobody noticed. Even at hourly, they are not a downtime alert, because an hour of latency attached to an ambiguous signal is not something anyone can act on immediately.
What to pair it with, and how the two fit
The complement to a client-side system is a server-side one, and the complement to a passive one is an active one. Uptime monitoring works by making requests to your site from outside your infrastructure on a schedule and judging the response, which means it learns about failures directly rather than inferring them from missing data. It sees the 503 that GA never hears about, because it is the thing receiving the 503.
The practical division of labour is clean. Monitoring answers whether the site is up, from where, and with what response, in near real time. Analytics answers who was affected and what it cost, after the fact and in business terms. Neither substitutes for the other, and teams that try to run incident detection on analytics discover the gap during their first real outage, usually because a customer emailed before any dashboard moved.
One configuration detail makes the pairing work better: keep the check interval short enough that the detection window is meaningfully smaller than an outage you would consider serious, since a check every five minutes averages roughly two and a half minutes of undetected failure before anyone hears anything.
Common mistakes in using analytics for downtime
Treating a flat line as an outage confirmation. Traffic at zero has at least three common causes: the site is down, the tag is broken, or the tag is being blocked. Confirm which before responding, because the fixes have nothing in common.
Relying on GA4 custom insights as an alert. Hourly evaluation exists for web data, but an hour of latency, plus weeks of model training before anomaly detection is reliable, makes this a backstop rather than an alert.
Monitoring only the homepage while measuring the whole funnel in GA. Partial outages are the common case, and a healthy homepage keeps analytics looking normal while a broken checkout quietly loses money.
Assuming the real-time report is a monitor. It updates quickly and it is genuinely useful for confirming a suspicion, but it requires a human to be watching, which nobody is at three in the morning.
Concluding the site is fine because sessions look normal. Sessions come from pages that loaded. They tell you nothing about the requests that never got a response, which is the entire population you are worried about.
FAQ
Can Google Analytics detect downtime?
No. GA only records events from pages that loaded and executed its tag, so an outage produces no data rather than an error. The gap in the data is the only trace, and it appears well after the fact.
Does Google Analytics show if a site is down?
Only indirectly, as an absence of sessions, and that absence has other causes including a broken or blocked tag. It cannot distinguish an outage from a tracking failure, which makes it unreliable as a signal on its own.
Can I set up a Google Analytics alert for an outage?
You can create custom insights that notify you about anomalous traffic drops, and they can be evaluated hourly for web data. An hour of latency is still not incident response, and the alert cannot tell you whether the cause was downtime or a broken tag, so treat them as a backstop rather than an alert.
What should I use instead to detect downtime?
An external uptime monitor that requests your pages on a schedule and evaluates the response directly. It detects failures that never reach a browser, which is the exact class analytics is blind to, and it can alert in minutes rather than at the top of the next hour.
Closing thought
The instinct behind this question is a good one. Analytics is already installed, already collecting, and already the place you look when you want to know how the site is doing, so it feels like it should be able to say when the site is not doing anything at all. The architecture just points the other way. A system that learns only from successful page loads cannot report on failed ones, and no amount of configuration reverses that. Keep GA for scope and impact, and get detection from something that talks to your server directly.
If you want the detection half covered, Odown checks your site from seventeen global locations at intervals down to one minute, on every plan including the twelve dollar tier, and alerts through Slack, Discord, Telegram, PagerDuty, Opsgenie, email, or webhooks. Point checks at the pages that matter rather than just the homepage, and the flat line in your analytics becomes something you can already explain by the time you see it.
