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. All of them are describing the same afternoon, and the vendor's own page, such as GitHub Status, is only one more voice.
The sites 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.
What evidence do "is it down" sites use?
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: 195 active services as of 2026-10-05, probed from up to ten regions, each against an endpoint chosen by hand, 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.
The banner, the incident feed and the component board are separate things a human updates, and they do not always move together. We walked through one afternoon at OpenAI using the timestamps on OpenAI's own status page. 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. A probe works for services with a hundred users as well as for services with a billion, and a viral post cannot move it.
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 do the sites disagree during an incident?
The sites disagree because each one learns about the incident at a different minute. 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 and is re-checked. A probe site that publishes each region separately can show one region failing and the others fine.
- 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 shows a failed reading from one region. Each is describing its own evidence. Only one of them is telling you where.
Which one should you believe?
Believe the one whose evidence matches your question, and read the others as context. These habits help:
- 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, with the vendor's status-page claim beside it where we ingest that feed. The methodology is public. A reading is one measurement from one place at one time: it says a request failed or succeeded, not that the service is down for everyone. Our probes can be the thing at fault, a probe region losing its own network path for example, and when that happens we retract what we published and list it at /outages/corrections.
A report spike can make us look sooner, but a report is never evidence in what we publish. And we say "awaiting data" rather than "operational" when we have no reading.
Our approach makes us narrower than a hybrid and more cautious than a report site. When a page here shows a failed reading from Tokyo, a request from Tokyo failed. You can see when, and you can see what the other regions read at the same time.
If you want those readings for services you depend on, without visiting a page: every catalog service has a feed and an embeddable badge.