Search "is GitHub down" during an incident and the first page of results will disagree with itself. One site shows a spike of reports. One says all systems operational. One says a partial outage was confirmed 40 minutes ago. One shows a probe reading from four cities. They are all describing the same afternoon.
They disagree because they are not measuring the same thing. There are four kinds of evidence an "is it down" site can be built on, and each has a specific blind spot. Knowing which one you are looking at is most of the skill.
The four kinds of evidence
Crowd reports. Downdetector is the best-known example. People who cannot reach a service click "I have a problem," and the site compares the rate of reports against a baseline for that service. Some sites also mine social media for complaints. A spike above baseline is shown as a problem.
The vendor's own status page. IsDown and StatusGator started here: they poll thousands of official status pages (Atlassian Statuspage, incident.io, and the rest) every few minutes and surface what the vendor has published. Both have since added user reports as an early-warning layer, so they are now hybrids, but the vendor's claim remains the backbone.
Direct measurement. A probe sends a real request to the service from a known location and judges the response. This is what an uptime monitor does for your own site, pointed at someone else's. It is how the RealUptime outages catalog works: more than 900 services, probed from ten regions, each against a hand-verified endpoint with a stated expectation of what healthy looks like.
Mixes of the above. Most sites now blend at least two. That helps coverage and hurts clarity, because the reader usually cannot tell which source produced the verdict on screen.
What each one can and cannot know
Crowd reports
Can know: that a lot of people are having trouble right now. For a widely used consumer service, a report spike is often the earliest public signal of a real incident, minutes ahead of anything official.
Cannot know: whether the service is actually down. Reports measure attention. A viral post produces reports from people who read the post. An ISP outage in one city produces reports against every service those users tried. A service with few users never spikes at all, however broken it is. And there is no denominator: the site knows how many people reported a problem, not how many were using the service fine, so it cannot state an error rate.
Read it as: "something is bothering a lot of people, possibly this." We covered the biases in detail in how Downdetector works.
The vendor's status page
Can know: what the vendor has decided to say. When a status page says "partial outage, identified, affecting the API in us-east," that is accurate, specific, and written by the people fixing it.
Cannot know: anything the vendor has not published yet. Status pages lag the incident, sometimes by a long way, because updating them is a human decision made by people who are busy. Component boards can stay green through a major incident while the banner admits a problem; we documented one such afternoon at OpenAI minute by minute. A status page also cannot see a regional failure the vendor's own monitoring does not distinguish.
Read it as: "the vendor has confirmed this much." Confirmation is valuable. It is just late, and its absence proves nothing.
Direct measurement
Can know: whether a specific request, from a specific place, got a healthy answer at a specific time. Repeated from several regions, that becomes "down from Frankfurt and Tokyo, fine from Virginia," which no other kind of evidence can produce. It works for services with a hundred users as well as for services with a billion, and it cannot be moved by a viral post.
Cannot know: what it did not probe. A probe hitting the API sees the API. If the outage is in the mobile app's login flow, a healthy API reading is true and unhelpful. A probe also sees only the paths it is allowed to see: services that bot-wall unauthenticated requests cannot be honestly measured, which is why our catalog rejects them rather than showing a green mark that means nothing.
Read it as: "this endpoint, from these places, right now." The most specific evidence, and the narrowest.
Hybrids
Can know: more, in total. A report spike plus a probe failure plus a status update is about as certain as it gets.
Cannot know: which of its inputs produced the verdict, unless it tells you. A hybrid that says "down" because of reports alone is a crowd site with a confident font.
Why they disagree, in practice
Put the four in a timeline of a typical incident and the disagreement resolves into sequence.
- Minute 0: the service breaks for some users in some region.
- Minute 2: a probe from the affected region fails, is re-checked, fails again, and that region flips to down. A probe site shows one region red, three green.
- Minute 5: crowd reports start climbing. If the service is popular, a report site shows a spike. If it is not, nothing.
- Minute 20 to 60: the vendor posts "investigating." Status-page aggregators update.
- Minute 90: the vendor updates components. The board goes from green to partial.
- After: the vendor's postmortem says it started at minute 0.
At minute 10, the report site says down, the aggregator says operational, and the probe site says down in Europe. All three are correct about their evidence. Only one of them is telling you where.
How to read them together
- Start with measurement, if you can get it. It answers "is it actually broken, and from where" without a crowd or a vendor in the loop.
- Use reports as an early signal, never as a verdict. A spike tells you to go look. It does not tell you what you will find.
- Use the status page for confirmation and detail, and treat its silence as silence, not as health.
- Mind the denominator. "3,000 reports" means nothing without knowing how many people use the thing. "12 of 14 services behind this provider are failing" is a statement with a denominator in it.
- Prefer sources that show their method. Any site that will not say what its verdict is built from is asking you to trust the font.
What we do, and what we do not claim
Every service page in our catalog shows the probe reading per region, the vendor's status-page claim beside it where we ingest that feed, and a scorecard comparing the two over time, so you can see how often a given vendor's page admitted an outage our probes measured. The methodology is public. We do not count reports, because we would have the same attention problem everyone else has, and we say "awaiting data" rather than "operational" when we have no reading.
That makes us slower to shout than a report site, sometimes by a few minutes, and narrower than a hybrid. It also means when a page here says down in Tokyo, a request from Tokyo actually failed, twice, and you can see when.
If you want that reading for services you depend on, without visiting a page: every catalog service has a feed, an embeddable badge, and a vendor watch that alerts when our probes confirm an outage, not when the crowd gets nervous.