How we measure
Every verdict on this site is backed by a timestamped network measurement from a testing location near you. No complaint counts, no tweet volume, no inference from page-view spikes. Here's the whole methodology, end to end.
What we measure
Three signals, in this order of precedence. HTTP is the primary verdict; ping and DNS classify failures when HTTP fails.
HTTP
A real GET against the service's known-good URL. We record status code and time-to-first-byte. A 2xx or 3xx inside the 20-second timeout is healthy — or, for bot-protected entries, the expected status we record per service (explained under "How we read the results"). CDNs answer ping while origins burn, so HTTP — not ping — has to carry the "Up" call.
Ping
ICMP echo to the resolved IP, used to separate "the network can't reach the host" from "the application is broken". Ping never produces an "Up" verdict on its own; it only narrows down a failing HTTP check.
DNS
A live A-record lookup from the same testing location. When resolution fails while the underlying IP still answers ping, that's a DNS issue — a different and often actionable kind of outage from a hard-down origin.
Where the measurements come from
Measurements run on an independent network of testing locations operated by third parties around the world. We request each measurement and read back the results.
Each measurement is targeted at testing locations near the visitor through an ordered location chain — ASN first, then city and country, then continent — so the result reflects the path between the visitor's network and the service, not an arbitrary datacenter. The hot tier covers four continents (North America, Europe, Asia, Oceania); the warm tier covers two. Every result page surfaces the city and network behind each measurement; precise locations are not.
When a measurement runs from a network provider on the visitor's own ASN we say so on the result page. That's the closest thing to "tested from your ISP" an independent testing network can produce, and it's a real differentiator from any tool that measures from a single fixed location.
How we read the results
The verdict engine reduces a set of measurements to one of five labels per region. Same vocabulary as the legend on the home page.
| Verdict | Rule |
|---|---|
| Up | At least two of three testing locations returned a healthy HTTP response inside the 20-second timeout. |
| Degraded | Mixed pass/fail across testing locations, or median response time more than 3× the service's 7-day regional median and above 800 ms, sustained on 2 consecutive checks. |
| DNS issue | Name resolution is failing across testing locations while the underlying IP still answers ping. |
| Down (regional) | Two of three testing locations in one region hard-failed HTTP; other regions still succeed. |
| Down (global) | Every measured region hard-failed HTTP in the same cycle. |
One wrinkle: some services gate automated datacenter traffic behind bot protection. Instead of serving the page, their edge answers with a fast, completed 4xx — a 403 bot challenge, a 405 from a WAF rejecting our bare GET, a 406 from a content-negotiation gate, or a 429 from a rate limiter. For those catalog entries we record the expected status per service and count it as healthy: a fast block response proves the service is reachable, so we count it as up. A bot gate that is itself failing — a transport error or a 5xx — still reads Down. Whenever this applies to a result you're looking at, the status page says so in a footnote under the measurement evidence.
The numbers
The exact thresholds the verdict engine runs on. Every value below is rendered from the engine's own constants — when the code changes, this page changes with it.
| Threshold | Value |
|---|---|
| HTTP timeout | 20 seconds. A request that hasn't answered by then is a hard fail, whatever it would eventually have returned. |
| Degraded by latency | Median time-to-first-byte more than 3× that service's 7-day median for the same region, and above an absolute floor of 800 ms — 3× a fast baseline is still fast, and no one experiences 150 ms as an outage. The condition also has to hold on 2 consecutive checks for the same region before anything publishes; a single slow sample never changes a verdict or opens an incident. The baseline needs at least 24 in-window samples before this rule fires; below that it stays dormant rather than guessing what "normal" looks like for a service we only just started watching. |
| Hot tier cadence | Every 10 minutes, tightening to every 5 minutes while a confirmed failure is being re-checked. |
| Warm tier cadence | Every 30 minutes. |
| Retention | Raw per-region measurement rows are kept for 30 days; the aggregates that feed timelines are kept for 90 days. |
The cadences are targets, not promises. The poller spends from a fixed measurement budget, and when the budget tightens the intervals stretch rather than measurements being dropped silently. The honest answer to "how fresh is this verdict?" is the "last checked" stamp on every card and status page — that's the real age of the measurement behind it.
What we don't do
The deliberate exclusions are as much the methodology as what we measure.
We do not aggregate user complaints into a verdict. We do not infer outages from tweet volume or social media sentiment. We do not treat a page-view spike on a status page as evidence that the underlying service is down. Those signals can be noisy, slow, and trivially gamed — and a complaint graph can't tell you whether the problem is on the service, between networks, or inside your own connection. The "Down for me too" button on a status page records a regional report, but reports are an overlay and an escalation trigger, never the verdict.
Status data as JSON
The same verdicts, machine-readable.
Every service's current verdict is available as read-only JSON at https://detectdown.me/api/v1/status/<slug> — the same cached measurement behind the status page, including the per-region verdicts and the list of regions we actually monitor for that service. No key required, CORS-open, cached on the same schedule as the page; it never triggers a new measurement.
Privacy and attribution
Two short rules that we lean into rather than bury in a policy page.
Your IP address is resolved once in memory for a single MaxMind geolocation lookup and a hashed rate-limit counter. It is not written to disk, it is not shared with the third parties who run our measurements, and it is not retained after the response is rendered. They receive only the location targeting derived from your IP (continent, country, city, ASN), never the address itself.
Geolocation data on this site is GeoLite2, created by MaxMind. The footer on every page carries the attribution required by the GeoLite2 license.