Outage tracker
Is the internet down?
When many services fail at the same time it is usually not many outages: it is one incident at a layer they share, a CDN, a cloud region, a transit route. We probe 195 services from four regions on our own schedule, and this page reads all of those measurements together. A provider is named only when at least 5 services that measurably sit behind it are probe-confirmed down at once while the services on other providers stay up. Nothing here comes from user reports, social posts or a vendor's status page, and nothing here changes any service's own verdict.
No shared incidentevaluated moments ago
The internet is not down
None of the 195 services we watch is probe-confirmed down right now.
Who sits behind whom: the measured dependency map
Of the 195 services we track, 195 have a recorded provider signal on their primary endpoint. A service can carry more than one signal (a CDN in front of a cloud region), so the rows overlap. Measured from our own probe responses, daily since Aug 23, 2026, last observation moments ago.
| Provider signal | Kind | Services | Share of catalog |
|---|---|---|---|
| Cloudflare | edge / CDN | 56 of 195 | 29% |
| Amazon CloudFront | edge / CDN | 38 of 195 | 19% |
| Google front end | cloud | 16 of 195 | 8% |
| Fastly | edge / CDN | 15 of 195 | 8% |
| Vercel | edge / CDN | 6 of 195 | 3% |
| AWS (load balancer or S3 front) | cloud | 5 of 195 | 3% |
| AWS us-east-1 (N. Virginia) | cloud region | 5 of 195 | 3% |
| Azure Front Door | edge / CDN | 3 of 195 | 2% |
| AWS us-west-2 (Oregon) | cloud region | 2 of 195 | 1% |
| Netlify | edge / CDN | 2 of 195 | 1% |
| Akamai | edge / CDN | 1 of 195 | 1% |
| AWS ap-northeast-1 (Tokyo) | cloud region | 1 of 195 | 1% |
| AWS eu-west-1 (Ireland) | cloud region | 1 of 195 | 1% |
Shared-infrastructure incidents, last 30 days
None declared in the last 30 days. That is a statement about what our correlation found, not a promise about the internet: an incident below 5 affected services, or one that also took down the services we use as a control group, is not declared here.
How this is measured, and what it cannot tell you
A provider signal is where a service's primary endpoint answered from. Every probe response carries two things we keep: the address our pinned socket actually dialed, and a short fixed set of edge-identifying response headers (cf-ray, x-amz-cf-pop, x-served-by, x-vercel-id, x-azure-ref, server, via). The address is matched against a small table of well-known provider ranges committed in our code (71 prefixes for Cloudflare, Fastly, a few AWS regions and Google, checked against the providers' published lists); the headers are matched only where a header is one that provider alone sets. A match says "this response came from behind X". No match says nothing. We never guess from a vendor name.
A provider incident is declared only when, inside a 15-minute window, at least 5 distinct services sharing one signal are probe-confirmed down (an outage our probes opened, which the database admits from probes alone) AND the control group, the services that carry some other signal, is mostly up: at most 20% of them down, over at least 10 of them. If the control group is failing too, the failure is broader than the provider and nothing is declared. It closes when the rule stops holding.
What it cannot tell you. It is a correlation we measured, not a root cause the provider has confirmed, and it can be wrong in both directions. It misses incidents at providers our prefix excerpt does not cover, incidents that affect fewer than 5 of the services we happen to track, and incidents behind a second layer we cannot see (a service on its own network whose database lives in a failing region). It can over-read a coincidence of unrelated outages behind one very popular provider, which is why the control group and the threshold exist. The dependency map counts only services whose primary endpoint answers from behind a provider; a service that uses a provider for something we do not probe is not on it. A service's own verdict on its own page is never changed by anything here.
Machine-readable: /api/v1/outages/internet (no key), and the is_the_internet_down tool on the keyless MCP server. Each service's JSON answer also carries its own provider signals under infra. Read the tracker methodology for what a single reading means.