Rules
How the check works, what counts as up, and where the public data comes from.
1. Check the target
We make recurring HTTP requests to downdetector.com and store the latest status, timestamp, HTTP result, and latency.
2. Publish incident records
Incident records open after repeated failed checks and close after repeated recoveries. Notes may be added when the record timeline needs context.
3. Expose the feed
The homepage, history page, and /api/v1/* endpoints read the same persisted check results and incident record data.
Incident semantics
Repeated failures open automated incident records after consecutive failed checks, then close after repeated recoveries.
Manual review means an operator opened an incident record after checking context that automation alone could not settle.
Reviewed as false alarm means an operator later decided the record should not be treated as a confirmed outage.
Incident record detail pages expand timelines and updates beyond the short summaries on the homepage and history views.
Notes
A response under HTTP 500 counts as reachable. That includes Cloudflare 403 responses: blocked is different from down.
This page explains the checking rules and data provenance; it is not a public source-code repository. Treat the live status as current truth only when the live status panel shows no freshness warning. For API consumers, apply the same rule when monitor.trusted is true and monitor.resultFreshness="current"; a 200 response can still carry an untrusted cached verdict when checks are stale or recovering.
For raw payloads, the public timeline, or help with an incident record label, use the links in Incident semantics above.