Multi-region monitoring is sold as the answer to "is it down for everyone?" It genuinely helps, and it settles less than it appears to. Every check location is still a machine in a datacenter, and the people using the service are not.
What multi-region genuinely buys ¶
- Distinguishing regional from global. The one thing it does well. Failing in two regions and fine in six is a strong signal, and no single vantage point can produce it.
- Corroboration before claiming an outage. One location failing is a fact about that location. Several failing independently is evidence about the target, and it is the only honest basis for the word "confirmed".
- Catching routing and BGP problems. These are inherently path-dependent and invisible from a single origin.
What it cannot buy ¶
1. Datacenter networks are not consumer networks
Every commercial monitoring location sits in a cloud region or a hosting facility. Real users are on residential broadband, mobile carriers and corporate networks, with different routes, different peering, and different DNS resolvers. A failure that affects one large consumer ISP is invisible from ten datacenters.
2. Sites treat datacenter traffic differently — on purpose
This is the sharpest limit, and the easiest to demonstrate. Netflix returns 403 to probes from cloud IP ranges while serving browsers normally. Airlines, banks and ticketing sites do the same. From ten regions you get ten 403s, which looks like overwhelming evidence of an outage and is evidence of a bot policy.
Handling that honestly means treating a refusal as its own category rather than a failure: the origin answered, it declined us, and we learned nothing about whether the service works. Counting it as downtime publishes a false outage with impressive-looking corroboration behind it.
3. Per-user and per-cohort failures
Gradual rollouts, feature flags, sharded data, account state. A deployment broken for 10% of accounts is invisible to every anonymous check from everywhere, because no check has an account. The full list of ways a service is up and down at once.
4. Short outages between polls
Ten locations checking every five minutes still leaves five-minute holes. More locations do not shrink the hole; more frequent checks do, and the two are usually traded against each other for cost.
What we do about it here, and what we do not claim ¶
This site's four probe methods differ by HTTP version, TLS strictness, verb and User-Agent — not by geography. That is deliberate, and it targets a different failure class: a site that serves HTTP/1.1 and not HTTP/2, or a browser User-Agent and not a plain one, is broken for a real slice of clients and no amount of geographic spread would reveal it.
The trade is that we cannot prove a global outage from one egress, so we do not say we can. A down verdict from central probes is marked unconfirmed; the word "confirmed" is reserved for independent locations agreeing. An outage claim is a statement about other people's experience and should require evidence about other people.
Getting closer to the truth ¶
- Your own error rates first. Real traffic from real networks is the only monitoring with no vantage-point problem at all.
- Then a check with a content assertion against the endpoint that matters, frequently.
- Then geographic spread, for the regional question specifically.
- Then reports from users, read as signal about which cohort rather than as a verdict.
The order matters. Most teams buy step three first because it is the one that is packaged and sold, and it is the one that answers the narrowest question.
The honest framing ¶
No external check proves a service is healthy. It proves the service answered a particular request, in a particular shape, from a particular place, at a particular moment. Everything beyond that is inference — worth making, worth labelling as inference, and worth keeping separate from what was measured.
What "confirmed" should actually require ¶
If a system is going to use that word, it should have to earn it. A workable bar, and the one used here:
- At least two independent locations, on infrastructure that is not shared with the primary prober. Two checks from the same cloud provider's two regions share a great deal of network path and are less independent than they look.
- Fresh. A vote from twenty minutes ago is describing a different incident.
- A majority agreeing, not merely a plurality, and with the disagreement recorded rather than discarded — a split vote is itself the finding when a failure is regional.
- Refusals excluded. A 403 from every location is unanimous agreement that we are being blocked, not that the site is down. Letting refusals count towards a quorum is how you build a very confident false positive.
Where the bar is not met, the honest output is a verdict marked unconfirmed rather than a hedge in the copy nobody reads.
Blind spots ranked by how often they bite ¶
- Per-cohort failures — rollouts, flags, shards. Most common, entirely invisible to anonymous checks.
- Bot policy — the site is fine and refuses you. Common on exactly the high-traffic consumer sites people check most.
- Consumer-network paths — one ISP, one carrier. Real users affected, no datacenter sees it.
- Sub-poll-interval outages — brief, repeated, and invisible between checks. Worst for long-running connections.
- Genuinely regional — the one multi-region is designed for, and the rarest of the five.
Worth noticing that the thing multi-region monitoring is sold on is last on that list. It is a real capability solving a real but uncommon problem, and the four above it need different tools.