What Downdetector actually measures
Downdetector's data comes from people, not probes. By its own description, the information it provides is based on user outage reports, collected from the report button on each service's Downdetector page and from social media. When the volume of reports for a service rises well above what is typical for that service at that time of day, the site flags a possible problem. The heat map on each page shows where reports are coming from.
That model has real strengths. Downdetector operates at a scale nobody else in the category matches: it reports tracking on the order of twelve thousand services across dozens of countries, and for a major consumer service, millions of visitors mean a genuine outage produces a report spike within minutes. For “is Instagram down” at 8pm, the crowd is a fast and usually accurate sensor.
What the model does not include, as far as its public materials describe, is any first-party measurement. We found no indication that Downdetector sends its own requests to the services it tracks. The signal is what people say, not what a machine observed. Every strength and every weakness on this page follows from that one design choice.
When a report spike is reliable
A crowd signal is most trustworthy when four things are true at once: the service has a large consumer user base, the failure is visible to ordinary users, the failure is widespread rather than regional, and it is happening at a time of day when users are active. A social network going down on a weekday evening checks every box, and Downdetector will show it fast and unambiguously.
Move away from any of those conditions and the signal degrades. A business tool at 3am has few users awake to complain. A failure confined to one region produces a small spike that may not clear the baseline. And a service whose users are mostly machines, like a payments API or a DNS provider, can be hard down for an hour before enough humans notice the downstream symptoms to file reports, and those reports often land on the wrong service's page, because users blame the app they can see rather than the infrastructure behind it.
The four biases in crowd-reported outages
Consumer skew. Report volume tracks how many humans use a service directly, not how important the service is. Consumer apps look noisier than they are; infrastructure looks quieter than it is.
Location of complaint, not of failure. The heat map shows where reporters live, which mostly means where the service's users live. A dense cluster over a big city is expected on every incident and says little about which region or data center actually failed.
Misattribution. When shared infrastructure fails, users report the apps they were using. A CDN or cloud-region incident shows up as simultaneous spikes on dozens of unrelated services, and the page for the actual cause may stay quiet.
Feedback loops. News coverage and social posts saying a service is down send curious users to Downdetector, where some file reports of problems they did not independently experience, or report ordinary local issues they would otherwise have ignored. The spike can outlive the outage, and occasionally a spike forms around an outage that never happened.
None of these are flaws in Downdetector's execution. They are properties of crowd-reported data itself, and they apply to any tool built on it, including the user reports we collect ourselves.
What is not published
The baseline idea is public, but the specifics are not: we could not locate a Downdetector-authored methodology page stating what counts as a significant deviation, how reports are deduplicated or verified, or how social media mentions are weighted. That does not mean the internal method is bad. It means an outside reader cannot check it, and cannot know whether two spikes of equal height on two different services represent equal evidence.
For context on who runs it: Downdetector is operated by Ookla, the Speedtest company, which has been part of Ziff Davis, with an acquisition of the Ookla group by Accenture announced in March 2026. The consumer site is free to read and ad-supported, with a paid enterprise product sold alongside it.
How to verify an outage independently
Treat a Downdetector spike as a hypothesis, then look for evidence of a different kind before acting on it, especially before posting your own incident or paging someone.
First, test the service directly if you can: load the site, call the API endpoint you depend on, from more than one network if possible. Second, check a tracker that measures rather than aggregates, so you can see actual probe readings per region rather than complaint counts. Third, read the vendor's own status page, remembering that vendors update late and undersell. When measurement, crowd reports, and the vendor's account agree, you know what is happening. When they disagree, the measurement is the one to trust first, because it is the only one of the three with neither an incentive nor an attention bias.
How RealUptime Outages handles this
RealUptime Outages keeps the two kinds of evidence separate by design. Every service in our catalog is actively measured by our own probes from four regions, on a cadence between 60 seconds and 30 minutes depending on the service, and each outage page shows the per-region readings. User reports are collected too, but they are labeled unverified and never blended into the measured verdict: only a probe result can open or close an outage in our record. The thresholds are published in full on the methodology page, and we do not store reporter IP addresses. For a feature-by-feature comparison, see RealUptime Outages vs Downdetector.
Next