One internet, four speeds
We ping the same 190 services from Virginia, California, Frankfurt, and Tokyo every few minutes. The answers disagree more than you'd think.
Every hour, our probes make a few thousand requests to about 190 well-known services. The same request, from four places: Virginia, California, Frankfurt, Tokyo. Then we write down how long each one took.
Here is what that looked like in the hour this post went up:
| Region | median | p95 | p99 |
|---|---|---|---|
| Europe (fra) | 240 ms | 761 ms | 1,376 ms |
| US-West (sjc) | 268 ms | 826 ms | 1,253 ms |
| US-East (iad) | 411 ms | 1,128 ms | 1,859 ms |
| Asia-Pacific (nrt) | 565 ms | 1,419 ms | 2,212 ms |
Same services. Same minute. Frankfurt's median is less than half of Tokyo's. A user in Japan waits 2.2 seconds for the slowest 1% of requests that a user in Germany gets in 1.4.
None of this is a scandal. Most of these services are US-hosted, CDNs do what they can, and the speed of light through fiber under the Pacific is not negotiable. What makes the numbers worth publishing is what teams do with the single-region version of them.
The single-number trap
If you monitor your API from one location, you get one latency baseline. You tune your alert threshold to it. Say your checks run from us-east-1 and your median there is 300 ms, so you alert at 900.
Your customers in Tokyo are living at 565 ms on a good day. When something degrades regionally, say an edge pop starts timing out, their p95 blows through 2 seconds while your one probe in Virginia keeps reporting 300 ms, green across the board. The alert you carefully tuned cannot fire on a problem it cannot see.
The reverse also stings: teams that probe from a far region and alert on a threshold calibrated for a near one page themselves at 3 a.m. for latency that is simply what the ocean costs.
What the baselines drift tells you
We also keep a 7-day rolling baseline per region. Today US-East is running 1.3x its baseline (411 ms against 321). Not an outage. No service is down. Just the internet in one region having a mediocre morning, which is exactly the kind of thing that is invisible if your monitoring collapses the world into one number.
The full data is live at /outages/internet-weather, updated hourly, with a JSON feed if you want to pull it into your own dashboards. Methodology is documented there too: only our own probes, never customer traffic, and if we have not measured something we say so instead of guessing.
The point
Latency is a place, not a number. Measure from where your users are, set thresholds per region, and treat any monitoring product that shows you one global figure with the suspicion it has earned.