Methodology and data policy
How every number on this site is calculated, what it is worth, and the specific ways it can mislead you. This is the page we would want to read before trusting somebody else's uptime data.
Uptime
The uptime percentage is observed availability: The proportion of measured time in which our probe could reach the service and get a usable response.
It is calculated from recorded downtime seconds, not from the ratio of passed to failed checks. Those give different answers, and the second one is misleading: With a check every 20 minutes, one failed check out of seventy-two is not "98.6% uptime" - It is one confirmed outage of unknown length. So we derive downtime from the incident log, where every outage has a real start and end, and express it as a fraction of the days we actually measured.
What this means in practice: Our uptime figure will usually be higher than the service's true availability, because we cannot see short, regional or feature-level failures. Treat it as a floor on how bad things were, not a ceiling.
A service with fewer than a day of history shows no uptime figure at all rather than a meaningless 100%.
Response time
The time reported is from the start of the HTTP request to the first bytes of the response body, measured after DNS and the TCP connection, which are timed separately. It is measured from a single location, so it reflects the path between our network and the service - Not what you would see, and not a global average.
Anything over three seconds is classified as slow. That threshold is arbitrary in the way all such thresholds are, but it is roughly where a page stops feeling like it is loading and starts feeling like it is broken.
Incidents
An incident opens on two consecutive failed checks and closes on the next successful one. Its start time is the first failure; its duration is the difference between that and the recovery.
The duration is therefore a lower bound with an upper bound of error equal to the check interval. A service that went down at 09:05 and recovered at 09:50 would, with checks at 09:00 and 10:00, either not appear at all or appear with quite different times. We record what we measured and do not smooth or estimate around it.
The "cause recorded" column is what our probe saw at the moment of failure - DNS lookup failed, Connection timed out, HTTP 503 from the origin. It is a symptom observed from outside, not the provider's own root cause, and it is labelled that way everywhere it appears.
User reports
Reports are anonymous and take one click, which makes them fast, useful and trivially easy to abuse. Four things constrain them:
- Rate limiting. One report per service per connection every thirty minutes, and eight reports across all services per connection per hour.
- A closed list of problem types. There is no free-text field, so there is nothing to fill with links.
- No effect on uptime. Reports cannot open, close or lengthen an incident, and cannot move the uptime percentage.
- A relative spike threshold. The status only changes to Reports when volume exceeds three times the service's own median non-zero bucket over the last fortnight, with a floor. A popular service has a permanent background hum of reports at all hours; an absolute threshold would flag it constantly.
The median rather than the mean is used deliberately: A single past incident would drag a mean upward for weeks and permanently raise the bar for detecting the next one.
Report locations
Where a report came from is asked, not inferred. We do not geolocate IP addresses. Commercial outage maps generally do, and the result looks precise while being wrong in two systematic ways: Consumer IP geolocation can be off by hundreds of kilometres, and anyone on a VPN is placed in the wrong country entirely.
The cost is that location is optional and most reports do not carry one. We think a sparse honest answer beats a dense confident one, and we do not draw a heat map from data that cannot support it.
What we store about you
For rate limiting we store a salted one-way hash of your IP address. The address itself is never written to disk. The hash cannot be reversed, and rotating the salt invalidates every hash we hold. Hashes attached to on-demand checks are deleted after seven days; those attached to reports are removed when the report ages out.
The on-demand checker stores the hostname you checked and the result. It does not store the path, the query string, or any association between a hostname and a person. The privacy policy is the complete version.
Which services get a page
A service appears in the directory when two things are true: We can meaningfully monitor it with an unauthenticated request to a public endpoint, and someone has written a genuine description of it - What it is, how it fails, what its symptoms look like.
Neither condition is negotiable, and the second is the one that keeps this site small. It would be trivial to generate a page for every domain that anyone has ever searched "is X down" for. Sites in this category routinely have tens of thousands of such pages, each containing a hostname, a ping time and nothing a human wrote. We would rather publish a hundred pages worth reading.
Services are retired by deactivation, never deletion, so their recorded history survives.
Known limitations, in one list
- Single vantage point: Regional outages are largely invisible to us.
- Check interval: Outages shorter than roughly 20 minutes may be missed.
- Home-page probe: Feature-level failures (login, checkout, messaging) do not register.
- Web only: Mobile app backends are not checked.
- Self-selected reports: Report volume reflects who visits this site, which skews towards English-speaking users and towards larger services.
- No authentication: Anything behind a login is out of scope.
If a number on this site matters to a decision you are making, the provider's own status page is the authoritative source and we link to it wherever one exists.