📡 Website Status Checker

About the Website Status Checker

This tool answers one question as precisely as it can: can a web server on the public internet be reached right now, and what does it say when you ask it?Every check runs from our server in the UK, so it tells you whether the site is reachable from the outside world — which is exactly what you cannot tell from your own machine when your ISP, your DNS resolver or your office firewall might be the real culprit.

What actually happens when you press Check

• DNS resolution — the hostname is resolved to one or more IP addresses, and that lookup is timed on its own.
• TCP connect — a plain socket is opened to port 443 (or 80, or whatever port you gave) and the handshake is timed.
• TLS handshake — for HTTPS, the connection is upgraded to TLS and that negotiation is timed separately.
• HTTP requests — several real GET requests are sent, following redirects by hand so the hops can be counted. Only the headers are kept; the page body is discarded rather than downloaded.

Each request is given a hard ten-second deadline. Only http:// andhttps:// are accepted, and private, loopback and link-local address space — 127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.0.0/16 and IPv6 ::1 — is refused, including after a redirect. That guard stops the tool being used to probe machines inside our network, and it means you cannot use it to test a site on your own LAN.

Why we take several samples

A single measurement is close to meaningless. The first request often lands on a cold cache, a sleeping serverless container or a fresh TLS session, while later requests reuse warm state and come back much faster. Taking three or five samples and reporting the minimum, mean and maximum tells you far more: a low minimum with a huge maximum points at an overloaded or cold-starting server, whereas three nearly identical numbers mean the site is genuinely steady.

What HTTP status codes mean, by class

• 1xx — Informational. Rare in practice. The server is acknowledging part of a request and continuing.
• 2xx — Success. The request worked. 200 OK is the normal healthy answer for a web page; 204 No Content and 206 Partial Content are also perfectly healthy.
• 3xx — Redirection. The content lives somewhere else. 301 and 308 are permanent, 302, 303 and 307 are temporary. This tool follows them and shows you the whole chain.
• 4xx — Client error. The server understood you and refused. 404 means the path does not exist, 401 means log in first, 403 means access denied, 429 means you are being rate limited.
• 5xx — Server error. The server broke while trying to answer. 500 is an application crash, 502 and 504 come from a proxy that could not reach or could not wait for the application behind it, and 503 usually means maintenance or overload.

Why a 403 or a 404 does not mean the site is down

This is the single most misread result in web monitoring. To return any HTTP status code at all, a server has to have accepted your TCP connection, completed the TLS handshake, parsed your request, routed it and generated a response. A404 is a working web server telling you, in good health, that it has nothing at that particular path. A 403 is a working web server deliberately refusing you — very often a bot filter or a web application firewall blocking an automated checker like this one, while a normal browser from a normal home connection gets straight through.

Genuine unavailability looks completely different, and the three flavours mean very different things:

• DNS did not resolve — the name has no records at all. The domain may have expired, the nameservers may be broken, or a recent DNS change has not propagated. Nothing was ever contacted, because there was no address to contact.
• Connection refused — the IP address answered immediately with a refusal. The machine is alive and on the network, but no web server is listening on that port. This is what a stopped web server looks like.
• Timed out — packets went out and nothing came back. Usually a firewall silently dropping traffic, a host that is switched off, or a server so overloaded it never gets to the accept queue.

There is a fourth case worth knowing: connected but errored. The TCP connection succeeded, so the machine is definitely up, but the request failed anyway — an expired TLS certificate, a certificate issued for the wrong hostname, or a connection reset mid-handshake. The server is running; the site is still broken for visitors.

Why response times vary so much by geography

Light in fibre travels at roughly 200,000 km per second, and real routes are never straight lines. London to New York is about 5,600 km, which costs a bare minimum of around 28 ms one way — 56 ms for a single round trip, before any server does any work. London to Sydney is nearer 250 ms round trip. That floor is physics, and no amount of server tuning removes it.

Then multiply it. Opening a TCP connection costs one round trip. A TLS 1.3 handshake costs another (TLS 1.2 costs two). Only then does the HTTP request go out and the response come back. A site whose server sits in Sydney can therefore take the better part of a second to respond to a fresh connection from the UK while feeling instant to an Australian visitor.

• Where the origin server lives relative to whoever is measuring — this tool measures from the UK.
• Whether a CDN is in front of it. Anycast CDNs such as Cloudflare or Fastly answer from a nearby edge, so the number you see is the distance to the edge, not to the origin. A cache miss quietly reintroduces the full origin round trip.
• Routing quality. Traffic rarely takes the shortest physical path; peering disputes and congested transit can add tens of milliseconds.
• Server-side work. Database queries, cold serverless starts and unwarmed caches all land on top of the network time.

The practical upshot: compare a site against itself over time rather than against someone else's numbers, and read the DNS, TCP and TLS breakdown before blaming the application. If the connect time is fine but the total is slow, the problem is the code. If the connect time itself is slow, the problem is the network or the distance.

Interpreting the timing breakdown

• DNS lookup — measured through the operating system resolver, so a cached name can legitimately report close to zero. A cold lookup of 20–100 ms is normal; consistently high figures suggest slow nameservers.
• TCP connect — one round trip. This is your cleanest proxy for raw network distance to the server.
• TLS handshake — the cost of negotiating encryption, typically similar to the TCP time on TLS 1.3.
• Total response — measured from the first byte sent to the response headers arriving, across every redirect hop. Subtract the connect figures and what remains is the server thinking.