How does the tool tell whether the site is down for everyone or only for me?

The tool runs reachability probes from multiple Cloudflare anycast points (RFC 4786 BCP 126 Abley & Lindqvist, December 2006), each in a different region. If every regional probe reports the site as unreachable, the outage is global — likely a server crash, DDoS, or origin misconfiguration. If only some regional probes fail, the issue is partial — typically a CDN POP failure, regional ISP routing problem, or DNS propagation in progress. If every regional probe succeeds but you still can't reach the site, the issue is local to your network: ISP transit problem, DNS resolver cache holding stale records, browser cache serving an outdated 5xx, antivirus/firewall blocking, or a captive-portal hijack. The tool's output explicitly distinguishes these three patterns so you don't escalate a local problem to an on-call engineer.

What does 'connection refused' or 'timeout' mean in the report?

Both are TCP-layer failures per RFC 9293 (Eddy Ed., August 2022, STD 7 obsoleting RFC 793) — pre-HTTP. Connection refused means the TCP SYN reached the host but no service was listening on the requested port (process crashed, port firewall, server stopped). Timeout means the SYN or response packets never arrived — could be IP-layer unreachable (host down or routing broken per RFC 1122 §3.2.2 Braden, October 1989), firewall silently dropping packets, or the route between the probe and the target degrading. DNS resolves successfully and TLS hasn't started yet. The remediation differs: refused = check service health, timeout = check network path / firewall.

Is this tool a substitute for DownDetector or status pages?

Complementary, not substitute. DownDetector aggregates user reports — it reflects perceived outages from a self-selected sample (people actively complaining), so it's noisy and lags actual outages by minutes. A site's official status page (status.example.com) reflects the operator's own monitoring and is authoritative when published, but operators sometimes delay updates during incidents. This tool is a synthetic active probe — it tells you right now whether the site responds from multiple Cloudflare regions, what HTTP/TCP/DNS layer failed if it didn't, and whether your local network is the problem. Use all three: this tool for an immediate yes/no, status page for incident transparency, DownDetector for crowd-sourced corroboration.

Is It Down? Website Outage Checker — Local vs Distributed

Q: What's the difference between an HTTP 4xx and 5xx outage?

Per RFC 9110 §15 (Fielding, Nottingham & Reschke, June 2022), 4xx codes mean the server processed the request but rejected it for client-side reasons — 404 Not Found (path doesn't exist), 401/403 (auth failed), 429 (rate-limited), 451 (legal). The server is up; the request is the problem. 5xx codes mean the server itself failed — 500 Internal Server Error (application crash), 502/504 (upstream gateway failures, common when origin is overloaded), 503 Service Unavailable (intentional throttling or maintenance). 5xx is the real outage signal; 4xx means the server is healthy but your request specifically isn't valid. The tool reports the exact code so you know which remediation path applies.

Is It Down? — Multi-Region Probe & 5-Layer Failure Diagnostic

When a website doesn't load, the question is rarely 'is it broken?' but 'where exactly does it break?' Failures stack across five layers: DNS resolution (RFC 1035 §4.1.1 NXDOMAIN/SERVFAIL, Mockapetris 1987), IP-layer reachability (RFC 1122 §3.2.2 ICMP, Braden 1989), TCP connection establishment (RFC 9293 connection refused/timeout, Eddy 2022, STD 7), TLS handshake (RFC 8446, Rescorla 2018), and HTTP application response (RFC 9110 §15 status code classes 4xx/5xx, Fielding, Nottingham & Reschke, June 2022). Each layer fails differently and demands different remediation. This tool runs reachability probes from multiple Cloudflare anycast points (RFC 4786 BCP 126, Abley & Lindqvist, December 2006) — distinct geographic regions — and reports which layer broke and from which checkpoints, so you can immediately distinguish a real distributed outage from a local network problem (your ISP, DNS resolver, browser cache, captive portal, antivirus, or VPN). The diagnostic answers the canonical 'is it down for everyone or just me?' with a layered breakdown that maps directly to remediation paths.

How to check if a site is down

Enter the URL or domain you want to test — full URL with path is fine.
The tool runs reachability probes from multiple Cloudflare anycast regions (RFC 4786) and reports per-layer outcomes (DNS / TCP / TLS / HTTP).
Read the verdict: all regions fail → distributed outage; some fail → partial / regional issue; all succeed → likely local to your network.
Match the failed layer to the remediation: DNS = registrar/nameservers; TCP refused = service down; TCP timeout = network path; TLS = cert; HTTP 5xx = application layer.

Common use cases

Confirming a global outage before paging the on-call engineer — distributed multi-region failure is the threshold for distributed-incident escalation.
Ruling out local network issues (ISP transit, DNS cache, browser cache, captive portal) when your connection alone can't reach a site multiple regions can.
Identifying a partial CDN POP failure or regional ISP routing problem affecting a subset of users only.
Capturing layered evidence (DNS RCODE / TCP status / TLS error / HTTP code) for a support ticket so the operator can triage faster than 'site is broken' would allow.

Frequently asked questions

How does the tool tell if the site is down for everyone or only for me?

Probes from multiple Cloudflare anycast regions (RFC 4786 BCP 126). All fail = global outage. Some fail = partial/regional. All succeed but you can't reach = local to your network (ISP transit, DNS cache, browser cache, antivirus, captive portal). Three explicit patterns mapped to remediation paths.

What's the difference between an HTTP 4xx and 5xx outage?

Per RFC 9110 §15 (Fielding/Nottingham/Reschke June 2022): 4xx = server processed but rejected request (404, 401/403, 429, 451) — server is fine, your request isn't valid. 5xx = server itself failed (500 crash, 502/504 gateway, 503 maintenance) — the real outage signal.

What does 'connection refused' or 'timeout' mean?

Both are TCP-layer pre-HTTP failures per RFC 9293 (Eddy Ed., August 2022, STD 7). Refused = SYN reached host but no service listening on port (process crashed, firewall, server stopped). Timeout = packets never arrived — IP-layer unreachable per RFC 1122 §3.2.2, firewall dropping, or route degraded.

Why might DNS show NXDOMAIN or SERVFAIL?

Both are DNS-layer failures per RFC 1035 §4.1.1 (Mockapetris 1987). NXDOMAIN = domain doesn't exist (registrar deletion, expired registration, typo). SERVFAIL = resolver itself broke (upstream DNS misconfigured, DNSSEC validation failure, transient bug). Try a different resolver (1.1.1.1, 8.8.8.8) to confirm.

Is this a substitute for DownDetector or status pages?

Complementary. DownDetector aggregates user reports — noisy, lags actual outages. Operator status pages are authoritative when published but sometimes delayed. This tool is a synthetic active probe — immediate yes/no with layered failure breakdown. Use all three for full picture.

Local vs distributed outage — how to read the layered diagnostic

Three patterns emerge from the multi-region probe. (1) Every regional checkpoint reports unreachable: the outage is global. The layered breakdown tells you whether DNS, TCP, TLS, or HTTP failed first — this maps to a remediation path (DNS = registrar / authoritative nameserver issue; TCP refused = service down on origin; TCP timeout = network path or firewall; TLS = expired cert or chain misconfiguration per RFC 8446; HTTP 5xx = application-layer crash or upstream gateway failure). (2) Some regional checkpoints succeed and others fail: partial outage. CDN POP failure (single anycast node down), regional ISP routing problem, DNS propagation in progress after a record change, or a regional WAF rule misclassifying traffic. The remediation is geographic — check the failing region's CDN dashboard or trace from there. (3) All regional checkpoints succeed but you still can't reach the site: the problem is local. Common causes: ISP transit issue between you and the site's edge, DNS resolver cache holding stale records (flush with `ipconfig /flushdns` Windows or `sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder` macOS), browser cache serving an old 5xx response (hard refresh / incognito), antivirus or firewall blocking the host, or captive-portal hijack on hotel/airport Wi-Fi. The tool reports each pattern explicitly so you can route the issue to the right team — or skip the on-call escalation entirely when it's a problem on your end.

Multi-region anycast probes from Cloudflare edge (RFC 4786 BCP 126)
5-layer failure diagnostic (DNS / TCP / IP-ICMP / TLS / HTTP per RFC 1035 / 9293 / 1122 / 8446 / 9110)
Local vs distributed vs partial outage classification
HTTP 4xx (request rejected) vs 5xx (server failed) distinction per RFC 9110 §15
TCP connection refused vs timeout reporting (pre-HTTP layer)
DNS NXDOMAIN/SERVFAIL detection per RFC 1035 §4.1.1 (pre-HTTP)

Free. No signup. Browser tools (subnet, JWT, password strength) run locally; lookup tools query public APIs (Cloudflare DoH, RDAP, certificate logs). Full per-tool breakdown at /methodology/.

Sources (6)

Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Semantics. RFC 9110, IETF (June 2022 — STD 97 — §15 status code classes; distinguishes 4xx client-side from 5xx server-side failures).
Eddy, W. (Ed.) (2022). Transmission Control Protocol (TCP). RFC 9293, IETF (August 2022 — STD 7; obsoletes RFC 793; TCP connection refused/timeout semantics for pre-HTTP failure layer).
Mockapetris, P. (1987). Domain Names — Implementation and Specification. RFC 1035, IETF (November 1987 — §4.1.1 RCODE field NXDOMAIN/SERVFAIL pre-HTTP failure layer).
Braden, R. (Ed.) (1989). Requirements for Internet Hosts — Communication Layers. RFC 1122, IETF (October 1989 — STD 3 — §3.2.2 ICMP error reporting + IP-layer reachability requirements).
Abley, J., & Lindqvist, K. (2006). Operation of Anycast Services. RFC 4786, IETF (BCP 126, December 2006 — multi-region anycast routing foundation for distributed reachability probes).
Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, IETF (August 2018 — handshake failures separate from HTTP layer; cert/SNI errors).

These are the IETF RFCs, NIST publications, and W3C standards the tool implements or queries. Locate them on the IETF Datatracker (datatracker.ietf.org) or the official standards body.

Related guides

Uptime SLA Math — What 99.9% vs 99.99% Actually Means (and Costs)The real cost of each extra nine in your uptime SLA, in minutes of downtime, architecture changes, and engineering effort.

By Marco B. · Last verified June 2026 — runs in your browser