Every monitoring vendor tells you to check from multiple regions. Almost none of them show you what difference it actually makes. So we measured it: 198 widely used services, probed from 10 regions, 11,131,260 measurements between 2026-08-08 and 2026-10-14.

The short answer: it barely changes what you conclude about uptime, and it completely changes what you conclude about speed. Availability across the 10 regions spanned 0.234 percentage points. Average response time varied by 2.6×.

What each region saw

Region	Availability	Avg response	p95 response	Measurements
London, UK `lhr`	99.675%	334 ms	549 ms	688,834
Frankfurt, Europe `fra`	99.724%	338 ms	572 ms	1,728,304
San Jose, US-West `sjc`	99.751%	374 ms	667 ms	1,834,389
Ashburn, US-East `iad`	99.751%	374 ms	612 ms	1,849,366
Chicago, US-Central `ord`	99.688%	421 ms	730 ms	691,918
Toronto, Canada `yyz`	99.691%	423 ms	718 ms	692,976
Tokyo, Asia-Pacific `nrt`	99.726%	633 ms	1,055 ms	1,613,406
São Paulo, South America `gru`	99.517%	744 ms	1,224 ms	685,526
Singapore, Southeast Asia `sin`	99.637%	812 ms	1,286 ms	673,531
Sydney, Australia `syd`	99.524%	857 ms	1,370 ms	673,010

Sorted fastest to slowest. The availability column is the share of measurements where the service answered normally.

Why this is not the finding people expect

The intuition behind multi-region monitoring is usually “a service might be down in one place and up in another.” Over this window, that is not what the data shows. The services in this catalog are mostly global platforms behind CDNs, and when they are healthy they are healthy everywhere.

What does change, sharply, is latency. If your alerting threshold is a fixed response time, the region you check from decides whether you get paged. A threshold that is comfortable from London, UK can be permanently breached from Sydney, Australia without anything being wrong.

Methodology, including what we threw out

Probes run against each service's public status endpoint from all 10 regions and are aggregated into daily buckets. Latency is weighted by sample count rather than averaged across days, because days differ in how many samples they contain and averaging the averages quietly overweights the quiet ones.

Limits worth stating. This covers 2026-08-08 to 2026-10-14, a short window, and not long enough to say anything about rare events. A single bad hour at one provider moves these numbers. It is a snapshot of a working period, not a durability ranking, and we would rather say that than imply more precision than 198 services over that window can support. The window grows as we keep measuring.

What to do with this

If you monitor from one location, the risk you are carrying is mostly not “missing an outage other regions can see.” It is a latency baseline that does not match your users, and alert thresholds tuned to the wrong number.

We check from all 10 of these regions on the free tier, which is unusual mostly because region count is the thing competitors put behind the paywall. See the live readings these aggregates are built from, or start monitoring your own service.