How does this tool actually decide a site is up?

The tool sends an HTTP request from a Cloudflare edge server in a specific region and inspects the response status code per RFC 9110 §15 (Fielding, Nottingham & Reschke, 2022). A 2xx response means the server processed the request successfully. A 3xx redirects to another URL — the tool follows up to a sensible limit. A 4xx indicates the client made an invalid request (404 not found, 403 forbidden); the server is technically up but rejecting that path. A 5xx is a server-side error (500 internal, 502 bad gateway, 503 service unavailable, 504 gateway timeout) — server is processing but failing. The tool flags 'soft 200' cases where a 200 OK contains an obvious error page in the body — applications often return 200 for client-rendered errors instead of a proper 4xx/5xx, masking real outages from naive checkers.

Why does this tool show the site as up when my browser can't reach it?

The tool runs from neutral cloud infrastructure (Cloudflare's global network) which has direct peering to most major carriers and CDNs. Your local connection adds layers the tool doesn't see: your home/office router (firmware bugs, DNS misconfiguration), your ISP (regional outages, peering disputes that don't affect cloud routes), corporate VPN (split tunnel issues, DNS policy), browser cache (serving an outdated error page), browser extensions (ad blockers, security extensions), or operating system DNS resolver. If multiple checkpoints see the site as up but your specific connection cannot, the issue is in your local network path — try `dig` from command line, switch to mobile data, or check from a different network. The tool's verdict 'site is up' answers 'is the public internet reaching it', not 'is your specific connection reaching it'.

Website Status Checker — Uptime & Response Time

Q: What's the difference between DNS failure and HTTP failure?

Different network layers fail differently. DNS resolution happens before the HTTP request: the tool first asks a resolver to translate the hostname to an IP address. RFC 1035 §4.1.1 (Mockapetris, 1987) defines the response codes — RCODE 3 (NXDOMAIN, name error) means the domain doesn't exist or has been deleted; RCODE 2 (SERVFAIL, server failure) means the resolver couldn't process the query (broken DNSSEC chain, authoritative server timeout, etc.). Either DNS error blocks the HTTP request entirely. The tool reports DNS failures separately from HTTP failures because the remediation path differs: NXDOMAIN means the domain registration or DNS zone is gone, SERVFAIL means the nameserver is broken, while a successful resolution that then yields HTTP 5xx points to application-level issues.

Q: Why do response times vary so much across regions?

Two factors: physical distance and routing quality. Light in single-mode fibre travels at ~c/n where n≈1.47, giving ~5 ms one-way per 1000 km (~10 ms RTT) plus router-hop processing time. A site hosted in Frankfurt responds faster from Madrid than from São Paulo because the round-trip distance is shorter. Routing quality affects this further — peering arrangements, transit ISPs, and BGP policies determine which path packets actually take, which often isn't the shortest geographic route. Anycast deployment (RFC 4786 BCP 126, Abley & Lindqvist, 2006) lets a single IP address advertised in multiple locations route automatically to the nearest edge — Cloudflare, Google's 8.8.8.8, and Fastly typically achieve sub-50 ms response from regions with nearby edge presence (not globally consistent — interior Africa, Pacific islands, etc. still see higher latency). Non-anycast/CDN sites show 100-400 ms inter-region variation depending on origin location and intercontinental routing.

Q: What does HTTP 403 from every checkpoint mean?

The site is serving requests but actively rejecting them with 403 Forbidden. Three common causes: (1) WAF rules blocking the cloud IPs the tool runs from — Cloudflare, Vercel, Imperva default-deny ranges that include datacentre ASNs; (2) Geo-blocking refusing traffic from certain countries — common for compliance (GDPR, regional licensing) or anti-DDoS; (3) User-Agent filtering blocking 'bot' requests — though this tool sends a real Mozilla-style User-Agent. Actual end-user browsers in residential ISPs often pass through fine, so the apparent 403 is checkpoint-specific not a real outage. Try a different region, or fall back to checking the site from a browser on a residential connection.

Website Status Checker — HTTP, DNS, TLS Multi-Region Probe

Website status checking sends HTTP requests from a neutral cloud edge and analyses the response per RFC 9110 §15 (Fielding, Nottingham & Reschke, 2022). The tool probes from multiple regional Cloudflare points — leveraging the anycast routing model defined in RFC 4786 BCP 126 (Abley & Lindqvist, 2006) — to detect whether the site is reachable globally or only from certain regions. A 2xx status code means the server processed the request successfully; 3xx redirects to another URL; 4xx flags client-side issues (the server is up but rejecting that path); 5xx indicates server-side errors. The tool also distinguishes DNS failures (NXDOMAIN, SERVFAIL per RFC 1035 §4.1.1, Mockapetris 1987) from HTTP failures, since remediation paths differ. Response time under 300 ms is fast, under 1 second moderate, anything beyond suggests origin or routing issues. TLS handshake failures (RFC 8446 TLS 1.3, Rescorla 2018) are reported separately — expired certificates and chain misconfigurations show up here, not in HTTP status. Useful for verifying deployments, sanity-checking after DNS changes, and ruling out local-network issues.

How to check if a website is up

Enter the URL or domain you want to verify.
The tool sends HTTP requests from regional Cloudflare edge servers (anycast routing per RFC 4786) and reports status code, response time, and overall availability.
Compare the status code per RFC 9110 §15: 2xx working, 3xx redirect, 4xx client-side issues, 5xx server-side outages. DNS failures (NXDOMAIN/SERVFAIL) are flagged separately.
If every checkpoint sees the site as up but your specific connection cannot, the problem is in your local path (router, ISP, VPN, browser cache), not the server.

Common use cases

Sanity-checking a freshly deployed site before sharing the URL.
Verifying a client's site is reachable from Europe after hearing it was slow from South America.
Auditing uptime sporadically to catch issues before the monitoring pager goes off.
Ruling out a local ISP outage when your own browser cannot load a site.

Frequently asked questions

How does this tool decide a site is up?

Sends HTTP request from Cloudflare edge and inspects status (RFC 9110 §15). 2xx OK, 3xx redirects, 4xx client error (still serving), 5xx server error. Flags 'soft 200' where 200 returns an error page in body — common application masking.

What's the difference between DNS failure and HTTP failure?

DNS happens before HTTP: NXDOMAIN (RCODE 3) means the domain doesn't exist; SERVFAIL (RCODE 2) means the resolver broke (RFC 1035 §4.1.1). Either blocks HTTP entirely. The tool reports them separately because remediation paths differ.

Why do response times vary so much across regions?

Distance + routing. ~5 ms one-way per 1000 km in fibre (~10 ms RTT, refractive index ~1.47) plus router-hop overhead. Anycast (RFC 4786, Abley & Lindqvist 2006) lets a single IP reach the nearest edge — Cloudflare, 8.8.8.8, Fastly typically achieve sub-50 ms response from regions with nearby edge presence. Non-anycast/CDN sites show 100-400 ms inter-region variation.

What does HTTP 403 from every checkpoint mean?

Site serves but rejects. Three causes: WAF blocking cloud IPs, geo-blocks refusing certain countries, or User-Agent filters. End-users on residential ISPs often pass through fine — checkpoint 403 isn't always a real outage.

Why does the tool show the site as up when my browser can't reach it?

Tool runs from Cloudflare neutral edge with direct peering to major networks. Your local layers (router, ISP, VPN, browser cache, extensions) add paths the tool doesn't see. 'Site is up' answers 'public internet reaches it', not 'your specific connection reaches it'.

Why multi-region uptime checking matters — distinguishing failure layers

A single user reporting 'the site is down' could mean: an actual outage (server crashed, application bug, DDoS); a regional CDN POP failure (parts of the audience affected, others fine); a DNS propagation issue after a record change (RFC 1035); a TLS certificate expiry (RFC 8446 TLS 1.3 handshake failure); a WAF rule misclassifying legitimate traffic; or just the user's local ISP, router, browser, or cache. Distinguishing among these requires probing from multiple geographically distinct points. Anycast deployment (RFC 4786, Abley & Lindqvist 2006, BCP 126) is the modern foundation — a single IP advertised in dozens of locations routes automatically to the nearest edge, so the tool's checkpoint at Cloudflare's network reaches a site through the same path real users would. The status output distinguishes signal layers: DNS resolution (NXDOMAIN/SERVFAIL pre-HTTP), TCP connection (refused/timeout pre-HTTP), TLS handshake (cert/SNI errors pre-application), and HTTP response (the actual status code from the application). Each layer's failure points to a different remediation path. The tool also flags 'soft 200' patterns where applications return 200 OK with an error page body — common in single-page apps that handle errors client-side, which masks real outages from naive checkers that look only at the status code.

HTTP status code semantics per RFC 9110 §15 (200/3xx/4xx/5xx classes)
Multi-region probes via anycast (RFC 4786 BCP 126)
DNS failure detection (NXDOMAIN/SERVFAIL per RFC 1035 §4.1.1)
TLS handshake error detection (RFC 8446 TLS 1.3 layer)
Soft-200 detection (200 OK with error page body)
Response time rating (fast <300 ms / moderate <1 s / slow)

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 (4)

Fielding, R., Nottingham, M., & Reschke, J. (Eds.) (2022). HTTP Semantics. RFC 9110, IETF (§15 status code classes 1xx-5xx).
Mockapetris, P. (1987). Domain Names — Implementation and Specification. RFC 1035, IETF (§4.1.1 RCODE field — NXDOMAIN/SERVFAIL).
Abley, J., & Lindqvist, K. (2006). Operation of Anycast Services. RFC 4786, IETF (BCP 126 — multi-region anycast routing).
Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, IETF (handshake failures separate from HTTP layer).

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

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