Every few weeks the same moment happens to a lot of people at once. Slack will not load. Then a payment page hangs. Then someone asks in a chat that is also struggling whether "the internet is down." The honest answer is that the internet does not go down, but large pieces of it do, and telling a shared-infrastructure incident apart from your own network problem is a skill worth having.
This post has two halves. The first is the two-minute triage you can do from your desk. The second is how we decide, on the Is the internet down? page, to say a named provider is having an incident, and what we refuse to say.
The two-minute triage
Work from the nearest cause outward. Each step rules something out.
1. Is it one site or several? One site failing is that site's problem. Several unrelated sites failing at once, especially ones that share nothing obvious, points at something shared: a CDN, a DNS provider, a cloud region, or your own connection.
2. Is it just this network? Switch your phone off Wi-Fi and load the same sites on mobile data. If they load, the fault is between you and the internet: your router, your ISP, a VPN, or a corporate proxy. If they fail on mobile data too, the fault is further out.
3. Is it DNS? A page that fails instantly with a "server not found" style error, rather than hanging, is usually DNS. Try loading the site by a different route (a known IP, or a different DNS resolver on your device). ISP resolvers fail more often than the sites they resolve.
4. Does an outside vantage point agree? Use a checker that probes from somewhere that is not your network. Our is it down tool runs a live check from our probe regions. If the site answers from four regions and not from your desk, you have your answer.
5. Is a provider named? If several sites fail from outside too, look at what they share. That is the question the rest of this post is about, because it is the one that is usually answered badly.
Why "everyone is reporting it" is not evidence
The fastest sources during an incident are crowd reports and social media. They are also the least reliable at exactly the question you have: what is actually broken.
Crowd reports measure attention, not failure. A viral post that "Cloudflare is down" produces thousands of reports from people who could not load one site that happened to be behind Cloudflare, and thousands more from people who read the post and refreshed something. A report site sees a spike for Cloudflare and for every service that shares an edge with it. The spike is real; the attribution is a guess.
Vendor status pages are the opposite problem: accurate about what is on them and slow to put anything on them. We have written before about the gap between when a service breaks and when its status page admits it, and about a major incident that stayed green on the component board for its whole duration. During a shared-infrastructure incident, the provider's page is the last one to change, because the provider is busy.
Neither source can tell you, ten minutes in, whether the thing that is down is the provider or the services that depend on it.
How we decide to name a provider
The Is the internet down? page shows one of exactly three states, and every state is built from our own probe readings, never from reports, social posts, or vendor status claims.
Where the readings come from. We probe more than 900 public services from ten regions around the clock. Each service has a real endpoint, verified by hand before it was added, and a documented expectation of what healthy looks like. That gives a continuous, independent reading for every service, taken the same way from the same places.
The dependency map is measured, not assumed. For each service we track, we record which provider it answers from behind, based on the probe responses themselves: the headers and characteristics a request comes back with when it passes through Cloudflare, an AWS region, a given CDN. This is re-measured daily, because services move. So "how many of the services we track sit behind provider X" is a number we can print, and it is on the page.
A provider incident needs a cohort and a control. When services go down, we look at whether the ones failing share a provider, and, just as important, whether the ones that share that provider and are not failing are few enough for the pattern to mean anything. A minimum number of that provider's cohort must be down, and the services outside the cohort must be mostly healthy. If half the internet is failing regardless of provider, that is not a provider incident and the page will not call it one.
The three states, in plain words:
- No shared incident. Some services are down, and the page says how many out of how many, but nothing they share explains it.
- A named provider incident. The cohort rule was met. The page names the provider, lists the services affected, and states the confidence in one sentence, including how many of that provider's services are affected out of how many we track.
- Several unrelated outages. Enough services are down to notice, and no shared signal ties them together. The page says so instead of picking a villain.
Declared incidents are kept for 30 days on the same page, with the method written out in full next to them, so a claim we made last Tuesday can be checked against what actually happened.
What we will not do
- We will not name a provider because reports are spiking. Reports are not in the input.
- We will not name a provider because its status page says so. The status page is shown alongside our reading where we ingest it, labeled as the vendor's claim, but it does not drive the verdict.
- We will not say "operational" for a service we have not read. A service with no recent reading says awaiting data, not fine.
- We will not smooth a regional failure into a global one, or the reverse. Per-region results are the default view everywhere on the site.
This makes the page slower to shout than a report site, by a few minutes, and much less likely to be wrong. When it names a provider, it is because the measurement supports the name.
The slower signal: internet weather
Not every bad day is an outage. Sometimes everything is up and everything is slow, from one part of the world. The internet weather page shows, for each of our regions, response-time percentiles across the public services we watch, against that region's own seven-day baseline. A region running at twice its normal p95 with nothing actually down is a real condition, and it is the kind of thing that never appears on any status page because no single service is at fault.
It is measured by our probes, from named regions, at named hours, never from customer traffic, and there is a daily feed and a JSON endpoint if you want it somewhere other than a web page.
When it is you
Most of the time, step two of the triage ends the investigation: it loads on mobile data, so it is the office network. That is a good outcome. The point of an outside vantage point and a measured provider view is not to find a big incident every time. It is to be able to say, quickly and with evidence, "this is ours to fix" or "this is theirs, and here is who," and to be right either way.