Every hour, our probes make requests to about 180 well-known public services. Across the ten regions, roughly 21,000 of those readings an hour come back successful with a measurable response time (a 7-day average to 2026-10-05). Same services, ten regions. Then we write down how long each one took.
Here is what that looked like, averaged over the hourly figures from the seven days to 2026-10-05, for four of the ten regions:
| Region | median | p95 | p99 |
|---|---|---|---|
| Europe (fra) | 255 ms | 901 ms | 1,657 ms |
| US-East (iad) | 297 ms | 914 ms | 1,817 ms |
| US-West (sjc) | 332 ms | 1,240 ms | 2,000 ms |
| Asia-Pacific (nrt) | 499 ms | 1,428 ms | 2,293 ms |
Same services, same hours. Frankfurt's median is about half of Tokyo's. For the slowest 1% of requests, Japan waits about 2.3 seconds where Germany waits 1.7. The other regions land in the same spread: Sydney and Singapore average about 700 ms at the median, Sao Paulo about 630 ms.
These are one probe network's measurements of public endpoints, not a statement about any single service, and the hourly figures move. The live numbers are at /outages/internet-weather.
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 roughly 500 ms on a typical hour. When something degrades regionally, say an edge pop starts timing out, their p95 climbs well past its usual 1.4 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 baseline drift tells you
We also keep a 7-day rolling baseline per region, and a region reads "slower than usual" only after three consecutive hours with a median well above its own baseline. That is not an outage and it is not a claim about any one service. It is 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.