Live outage monitoring
Real-time status for the websites and services you rely on.
Every status on this site comes from rules you can read. This page explains what we measure, how a status is decided, and what we deliberately do not claim.
Last updated August 17, 2026
Official signals first
A provider's own status API or incident feed outranks our probe whenever one exists.
One failure proves nothing
A status changes to an outage only after failures repeat. Single blips are treated as transient.
Uncertain over wrong
When evidence conflicts or is thin, we publish status uncertain instead of a false outage.
Each service is evaluated from up to three independent inputs. They do not carry equal weight: an official provider signal can set a status on its own, while user reports can only support other evidence.
Official provider sources
Strongest signalA verified status API, RSS/Atom incident feed, or status page is treated as a strong official input. Source outages are tracked separately from service outages: if a status page is unreachable, we say the official source is temporarily unavailable rather than declaring the product down.
Independent HTTP checks
Second signalOur own probes measure reachability and response time from our monitoring location, and record timeouts and HTTP errors. They are the primary signal for services that publish no official feed.
Anonymous user reports
Supporting onlyReports from this site can corroborate other evidence and can surface app, login, API, or regional problems when the public website still responds. They are rate-limited, never stored with raw IP addresses, and never imported from other outage trackers.
Status is a rule-based combination of official signals, consecutive check results, and supporting user reports — not a model prediction. When a provider publishes a status, that value leads. Without an official feed, our own checks have to repeat before the status escalates:
One failed check
No changeTreated as a possible transient failure. The published status does not change.
Two failed checks in a row
Possible issuesEnough to flag that something may be wrong, not enough to call an outage.
Three or more failed checks in a row
Partial outageMajor outageThe observed severity is published — partial or major, depending on what the checks show.
User reports are layered on top of this. An elevated volume or a clear spike can raise a service to possible issues, which is the ceiling: reports alone never produce a partial or major outage, and they do not override a provider that is actively reporting its own status. When signals disagree or the evidence is thin, the result is status uncertain.
Several failure modes look like an outage from a single vantage point but are not evidence that a service is down for its users. None of these flip a service to an outage on their own:
These are the only six states a service page can show. The same labels and colors are used everywhere on the site.
An uptime percentage is published only when monitoring began at or before that window started. A service we have watched for four hours does not get a 30-day figure of 100% — it shows when monitoring started instead.
Sample count is not a substitute for coverage: seventy checks in an hour is not a month of observations. Where a window is not fully covered, we show the monitoring start date rather than a percentage.
Descriptive About sections (operator, launch date, platforms, and similar facts) may be researched or summarized with automated tools, including AI models, and are reviewed before publication.
AI is never used to determine live status, outage state, uptime, response time, or incident confidence. Those values come only from the rules described above.
Think a status is wrong?
Tell us which service and what you observed at contact@whosdowntoday.com. Methodology corrections are welcome.
See also Sources, uptime rankings and about this site.
