How we measure
Every verdict on detectdown is backed by cached, timestamped network measurements from independent testing locations. No complaint counts, no tweet volume, no guessing from traffic spikes. Here's the whole methodology, end to end.
Need per-region REST, webhooks, and SLA reports? Paid API early access
This page is generated from the verdict engine's own constants.
What we measure
Three signals. HTTP decides up or down; ping and DNS explain why when it fails.
1 HTTP primary
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. CDNs answer ping while origins burn, so HTTP, not ping, carries the "Up" call.
2 Ping classify
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 a failing HTTP check.
3 DNS classify
A live A-record lookup from the same network panel. When resolution fails on networks where 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
Cached catalog checks from the current North America precision panel, so no single location can decide a verdict.
Routine catalog checks currently run from the North America precision panel, the current measured region. The panel uses independent testing locations operated by third parties. We request each measurement and read back the results.
North America is the only routine measured region today; broader regional coverage and the zone layer remain disabled under the current plan and are future work.
Measurements run in the background for the service catalog and are cached for the status pages. Every monitored service is checked the same way, with no priority tiers. A visitor's location selects the most relevant cached regional framing; loading a page does not start a new measurement or spend measurement budget. Each routine sweep requests up to 6 testing locations per monitored service from North America. Status pages surface each testing city's result with its country and flag your network only when the testing network ASN matches the visitor ASN; precise coordinates are never shared.
Routine checks rotate that testing-location panel to keep every monitored service equally fresh within budget. A region's verdict is never published on one location's opinion alone: when HTTP smoke appears, the affected region is re-checked and can be confirmed by a dense HTTP-only burst of up to 15 testing locations. Ping and DNS stay in the classification path, where they explain whether a failing HTTP result is a network reachability problem or a DNS issue; they are not part of the wide HTTP burst. We only publish Down or Degraded when the trouble is corroborated across at least 2 independent networks. A lone flaky or blocked location is left out as inconclusive.
When a cached measurement came from a testing network whose ASN matches the visitor's own ASN, the result page labels that network as your network. 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
One bad reading is never an outage. Trouble has to show up across independent networks and survive a re-check.
The verdict engine reduces a set of measurements to one label per region. The hard part isn't reading "down", it's not crying wolf when the problem is on our side of the path.
Every testing location we measure from sits on a datacenter network. That's a feature for coverage, but it has a catch we take seriously: plenty of services rate-limit or outright block datacenter IP ranges, and datacenter-to-target paths occasionally just drop. So one location failing to reach a service is not the service being down. It might be that one network being blocked or flaky. We never publish Degraded or Down off a single location, a single network, or a one-off blip. A real problem has to show up across independent networks and hold up on a re-check before it ever reaches the page.
Every measurement is sorted into one of four kinds before any verdict is computed:
Only "target error" and "couldn't reach it" can move a verdict toward trouble, and only when they're corroborated across at least 2 independent networks. A 5xx or a timeout seen from a single network is treated as inconclusive, logged as location noise, and left out of the verdict. The escalation re-check reads each troubled region from a panel of independent testing locations, so a region only turns Down or Degraded when the trouble is the majority of that panel, never the one location that happened to be blocked.
| Verdict | Rule |
|---|---|
| Up | A majority of testing locations returned a healthy HTTP response inside the 20-second timeout. An isolated location error alongside that majority is location noise, not degradation. |
| Degraded | A 5xx confirmed from two or more independent networks (short of a full Down majority), 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 failed across two or more independent networks, or failed on those same networks while the underlying IP still answered ping. |
| Reachable (blocked from our testing networks) | The service answers only with refusals, or our datacenter locations can't reach it and the failure isn't corroborated across networks. Its own honest state: reachable, just not from where we test. Not an outage. |
| Down (regional) | Confirmed hard fails in the measured region in the same cycle, corroborated across independent networks. |
Because all our locations are on datacenter networks, "reachable (blocked from our testing networks)" is a real and honest answer, not a cop-out: a service can be perfectly up for users while refusing or dropping traffic from our testing locations. Rather than mislabel that as an outage, we name it for what it is.
Some catalog services we monitor sit behind bot protection that always answers a fast block, a 403, 405, 406, or 429, to datacenter traffic. For those we record the expected status per service: a fast block response proves the service is reachable, so we count it as up rather than blocked. A bot gate that is itself failing, a transport error or a 5xx, is outside that band and still reads Down.
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 | What it means |
|---|---|---|
| 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 | 3× · 800 ms · 2 checks | Median time-to-first-byte more than 3× the service's 7-day regional median, and above an absolute floor of 800 ms. The condition also has to hold on 2 consecutive checks, and the baseline needs at least 24 in-window samples before this rule fires. |
| High-confidence confirmation before going public | 2 networks | When a routine check reports a hard failure, the affected region is re-checked from a panel of independent testing locations. A region turns Degraded or Down only when trouble is corroborated across at least 2 independent networks in that panel, so one bad location cannot count on its own. A burst-corroborated problem can publish in that same cycle. |
| Fallback persistence before public | 2 cycles when no burst corroborates | When the burst cannot corroborate a problem, a problem verdict (Degraded, Down, or DNS issue) has to repeat on 2 consecutive measurement cycles before it flips the public verdict, lists the service under "Currently having problems", or opens an incident. Recovery is the opposite: the first healthy cycle clears it at once. |
| Excluding a fleet-wide measurement glitch | 50% | If more than 50% of the services measured in one cycle newly look Degraded or Down, we treat it as a problem on our measurement path and briefly hold those flips at the last healthy verdict. If the fleet-wide problem persists across consecutive cycles, the hold stands down and each service still has to pass the normal confirmation rules before an incident opens. |
| Quarantining an unreliable testing location | 50% · 7 days · 20 samples | A network that disagrees with peer consensus on more than 50% of its measurements over a rolling 7-day window, once it has at least 20 measurements to judge it on, is quarantined until its good measurements wash out the old disagreements. |
| Check cadence | 15 min · 5 min | Every monitored service is checked on the cadence shown here, tightening to the escalated cadence while a published incident is re-checked as capacity allows. |
| Routine capacity | 32 services · 1 region · 6 testing locations · 15 min | That routine plan runs about 128 service checks per hour: 32 services times 4 sweeps per hour. Each service check asks for 6 testing locations, for about 768 testing-location results per hour: 128 service checks times 6 testing locations. |
| Retention | 30 days · 90 days | 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 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
No complaint counts, no tweet volume, no traffic-spike guessing. Ever.
Connect your AI assistant
Use the status board from tools that support remote MCP connectors.
https://detectdown.me/mcp
claude.ai custom connectors: use Customize > Connectors, add a custom connector, paste the URL, then complete the email-code sign-in. Setup guide
ChatGPT: requires ChatGPT web access. OpenAI documents Apps, developer mode, and full MCP support for Business and Enterprise/Edu workspaces; Enterprise/Edu can authorize developers with RBAC. OpenAI also notes Pro users can connect MCPs with read/fetch permissions in developer mode while full MCP remains Business and Enterprise/Edu. Create the app from Apps, Scan Tools, finish OAuth if prompted, then Create. See the full setup guide on Connect. Setup guide
Cursor: add a remote MCP server in Cursor settings with the URL, then follow the OAuth sign-in. Setup guide
Claude Code: add the URL as a remote MCP server, then finish the browser-based authorization flow. Setup guide
VS Code: use Copilot Chat in Agent mode with MCP support, add an HTTP MCP server with the URL, then complete the browser sign-in. Setup guide
Status data, by API
Programmatic, evidence-based verdicts for your dashboards, alerting, and incident automation. A paid service, in early access.
The same measurements that drive this site, machine-readable: per-region verdicts, uptime history, and webhooks. So "what was the last-known verdict for this third party, and is that answer still fresh?" becomes a question your tooling can act on, with timestamps and stale signals from real network checks instead of complaint counts.
Per-region verdicts over REST, plus webhooks. Know it's down in a region before your users tell you.
Evidence, not complaints. Reliable enough to gate alerts and automation on.
"Is it us or them?" in one call. Stop paging on-call for a third party's outage.
Uptime history and SLA reports. For the vendors you actually depend on.
GET https://api.detectdown.me/v1/status/github
{
"slug": "github",
"name": "GitHub",
"verdict": "Up",
"verdict_class": "up",
"per_region": {"NA":"Up"},
"regions_monitored": ["NA"],
"measured_at_unix": 1700000000,
"measured_at": "2023-11-14T22:13:20Z",
"stale": true
}Privacy and attribution
Your IP is used once in memory, then dropped. Never stored, never shared.
Your IP address is resolved once in memory for a single MaxMind geolocation lookup. When you submit the API early-access form, a short-lived rate-limit counter also uses the IP address, keyed by a hash of the address, not the raw address. The IP address 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. Page views read cached measurements; they do not send visitor-IP-derived city, country, or ASN targeting to measurement providers.
The site also uses privacy-friendly, cookieless analytics. It sets no tracking cookies and collects no personal data, only aggregate page views and a few product events.
GeoLite2 data created by MaxMind, available from maxmind.com.