When you type a domain into WebsiteDown and press Check, you get a verdict a few seconds later: "Confirmed outage", "Likely regional or partial issue", "Operational". This article explains exactly how those verdicts are produced — every signal we collect, the actual thresholds we use, and the rules that combine them. It also covers the limits: the things a tool like this genuinely cannot know, and how we handle them.
Why publish the internals? Because an outage checker asks for your trust at precisely the moment you cannot verify anything yourself. The site you rely on is broken, you need a straight answer, and any tool can put a red banner on a page. We think the honest way to earn that trust is to show the machinery — including the parts where the honest answer is "probably" rather than "definitely".
One check, four layers
Every check starts with a server-side probe from our infrastructure — one request, issued from a single US-East serverless region. We are upfront about that: it is one vantage point, not a global probe network, and you will see later how we compensate for it.
But one probe is not one signal. The probe runs in layers, each answering a different question:
DNS consensus. We query the domain against multiple public resolvers (DNS-over-HTTPS providers plus the local resolver) and compare answers. If every resolver fails, the domain genuinely is not resolving — that alone explains an outage. If some resolve and some fail, that points to DNS propagation problems. If resolvers return entirely different addresses, that is usually geo-routed DNS, not an outage. Collapsing those three situations into "DNS is down" would be wrong three different ways.
HTTP with a real body read. We fetch the page and read up to 256 KiB of the response body — not just the status line. The reason is the silent-failure problem described in the next section.
TCP reachability. If the HTTP request fails, we separately test whether a raw TCP connection to the resolved address succeeds. This separates "the server is gone" from "the server is there but the web service on it is broken" — different failures with different recovery patterns.
TLS inspection. On HTTP failure we also complete a TLS handshake and inspect the certificate. An expired certificate otherwise presents as a generic connection error, and it deserves a specific verdict because the fix (renew the certificate) and the blame (the site operator, not the network) are both unambiguous.
One detail worth knowing: a 4xx response — a 404, a 403, even a 429 — counts as reachable. The origin answered; something is alive and making decisions. Only 5xx responses, timeouts, refused connections, and handshake failures count against reachability.
The silent-failure problem
A 200 OK can lie. A common failure mode for modern sites: the CDN stays up and returns 200 while the application behind it collapses, so the "page" is a 400-byte error shell where the real product is normally 40 KiB of HTML. A probe that only reads the status code calls that healthy.
Our defense is a per-service response fingerprint. As checks run, we record the response size of healthy-looking responses (status under 400, body over 100 bytes) into a running baseline. A later response whose body lands outside 0.3× to 3× of that baseline is flagged as content drift — the site is answering, but not with what it normally serves.
Two design choices keep this honest. First, we only learn from responses that already look healthy, because a baseline poisoned by error pages is worse than no baseline. Second, a baseline needs ten observations before we trust it; until then the check simply reports that no baseline exists and the drift rule stays silent. The 0.3×–3× envelope is deliberately loose — dynamic pages vary — but a 40 KiB to 400-byte collapse blows through it immediately.
Community reports: the regional signal
Our probe sees the internet from one place. Real users experience a service from thousands of networks, devices, and countries at once — and a large class of real outages is invisible from any single vantage point: geo-blocks, a failed CDN edge in one region, a login system that breaks while the homepage stays up.
That is what the report buttons are for. Every status page has "Report issue" and "It's working for me". Reports are stored with the report type, the country when the browser provides it, and an anonymized fingerprint used for deduplication — one frustrated person pressing the button repeatedly does not manufacture a spike.
We aggregate reports into 15-minute, hourly, and daily windows. The 15-minute window is the one detection cares about: it is fast enough to catch an incident forming and wide enough to smooth out noise. A probe returning 200 while dozens of people report failures within 15 minutes is not a contradiction — it is a signature. It usually means the outage is partial: regional, network-specific, or limited to one feature. Our verdict says exactly that instead of forcing a binary answer.
When does a spike become an incident?
Raw report counts mean nothing without context. Thirty reports in 15 minutes is a five-alarm fire for a mid-size service and background noise for a platform with hundreds of millions of users. So incident detection is relative to each service's own history.
Every five minutes, a job aggregates fresh reports and compares each service's 15-minute volume against that service's baseline — its historical average for the same window. An incident record opens only when two conditions hold at once: at least 5 reports in the window (an absolute floor, so a single-digit blip never pages anyone) and at least 3× the service's baseline. One threshold is absolute, one is relative, and both must fire.
Two more rules round it out. Two hundred or more reports in 15 minutes is treated as critical regardless of baseline — some signals are loud enough that history does not matter. And an open incident resolves only when volume falls back below 1.5× baseline. Opening at 3× but closing at 1.5× is deliberate hysteresis: without the gap, a service hovering near the line would flap between "incident" and "resolved" every five minutes.
Official status pages: authoritative, but mechanically slow
We poll the official status pages of the services we track on a roughly ten-minute cycle and record the vendor's own indicator — minor, major, or critical.
That signal is authoritative in our system. If a vendor's own dashboard says "major outage", it outranks our probe — even a probe that just got a clean 200. The vendor can see their internals; we cannot, and pretending otherwise would be exactly the kind of overclaim we built this system to avoid.
But official status pages have a structural weakness: they are updated by people, in the middle of incident response. Someone has to confirm the problem is real, decide it is worth declaring publicly, write the notice, and often clear it internally first. Community reports have no such pipeline — they begin the moment users hit errors, automatically. That is not a criticism of any vendor; it is just the mechanics of the two signals, and it is why report spikes usually move before official acknowledgment does. We track both because each covers the other's blind spot: reports are fast but noisy, status pages are slow but definitive.
The AI source scan — and what it deliberately does not do
For major services during active incidents, we also run an AI source scan: a real-time web search (via Perplexity's Sonar API) across social media, news, and status-page chatter, summarized into a few sentences. For everything else, a small model (Claude Haiku) summarizes the signals our own platform has already collected. The web-search path is aggressively cost-capped — it only runs for a curated list of top-tier services, with a hard limit of two calls per domain every two hours — so you will see it exactly where it is most useful and nowhere else.
Two rules govern this layer. First, every AI-generated claim is displayed with its sources, so you can read what it read. Second — and this matters — the AI never decides whether a site is up. The up/down verdict comes from the probe, the reports, and the rules described in this article. The AI summarizes context around the verdict; it does not verify anything, and we label it accordingly.
How the verdict is decided
All of these signals feed a single classifier: an ordered chain of rules where the first match wins. It is a pure function — same signals in, same verdict out — and it is written to be conservative: when rules disagree or evidence is thin, it deliberately downgrades rather than rounding up to a scarier headline. The core of the ladder:
Certificate expired — the probe failed and TLS inspection confirmed the certificate is past its expiry. A specific, actionable verdict that fires before any generic outage rule.
Confirmed outage — the probe failed AND at least 10 user reports arrived in the last 15 minutes (or an incident record is already open). A probe failure alone can never produce "confirmed", no matter how decisive it looks. Confirmation requires corroboration by definition.
High-confidence outage — the probe failed and reports exist but are thinner: at least 3 in 15 minutes, or 10 in the past hour.
Probable outage — the probe failed and reports are thin or absent. This is the honest middle: maybe user traffic has not caught up yet, or the service is too small to generate reports at all. We say "probable" and show the probe evidence.
Likely regional or partial — the probe SUCCEEDED, but at least 10 reports arrived in 15 minutes, or reports are mixed (some users reporting failures while others confirm it works). Mixed signals never read as a full outage — they read as what they are.
Silent failure — the probe got a 200, but the response body drifted outside the fingerprint envelope described earlier.
Every verdict ships with its reasoning — the actual evidence lines, like "Server probe failed (HTTP 503)" and "14 user reports in the last 15 min" — so you are never asked to trust a colored badge on its own.
What we deliberately do not claim
A methodology writeup is only useful if it includes the limits, so here are ours.
One probe region. The outage check and continuous monitoring run from a single US-East region per check. We do not claim global probe coverage — the regional signal comes from community reports, official status pages, and (on the speed test) a separate, clearly-labeled panel that measures reachability from five named regions on demand.
No invented uptime numbers. We do not publish uptime percentages for services we do not continuously monitor. Where you see outage history on our pages, it is built from detected incidents and report volume — never extrapolated into a fake "99.94%".
Honest alert timing. Paid monitors are checked every 60 seconds, free monitors every 5 minutes, and alerts fire within 1–5 minutes of detection — not "instantly", because nothing polling on an interval is instant. We also suppress alerts for monitors that recovered within the previous 15 minutes: the incident is still recorded, but a flapping site should not page you every 90 seconds.
The AI does not verify. It summarizes sources it shows you. The verdict machinery above never delegates to it.
See it run
The fastest way to evaluate any of this is to watch it work. Run a check on a service you use — the evidence panel under the verdict shows exactly which of these signals fired and what each contributed. During the next big outage, compare what the report curve does against the moment the official status page turns yellow.
And if you find a case where our verdict was wrong — a "probable outage" that was actually your ISP, an incident we called too late — we genuinely want to hear about it through the contact page. A detection system improves by being auditable, and this article exists so you can audit ours.