HTTP status code checker: what the number actually tells you
An HTTP status code checker reads the number a server sends back. How to check HTTP status and use an HTTPS status checker, including when a 200 still means the page is broken.
An HTTP status code checker answers a narrower question than most people expect. The server sends a three-digit code before any HTML, and that code says how the server handled the request. It does not say the page rendered, the login works, or the site is up for everyone else.
Check HTTP status from outside your own network
The usual reason to check HTTP status is “is this site down, or is it just me?”. A check from your laptop uses your DNS, your ISP and your browser cache. If those are the broken part, the code you see is a local story. A check from another network answers a different question: did this server answer someone who is not you?
Our free “is it down” check does that from a server in Zurich. It fetches response headers only — no page body — and treats a final status from 200 up to, but not including, 400 as “it responded”. A 404 or a 500 is “it did not respond properly”. One city cannot tell you the site is down everywhere. A site can answer Zurich and still fail on your phone.
HTTPS status checker: the lock is not the status code
An HTTPS status checker still returns an HTTP status code. The “S” means the request travelled over TLS. A 200 on https:// tells you the handshake succeeded and the server answered. It does not grade the certificate, and a failed handshake never produces a status code at all — the connection dies before HTTP starts. Certificate expiry and trust are a separate check.
HTTP response checker: follow the redirect, then read the code
A response checker that stops at the first hop will report 301 or 302 for a site that is actually fine. The interesting code is the one at the end of the chain. A 301 means the address moved for good and clients should remember the new one. A 302 means the redirect is temporary and the original address stays the canonical one. A 304 means the cached copy is still current, so no body was sent.
“Check HTTP to HTTPS redirect” is the same idea with a specific hope: that http:// answers with a redirect to https://, and that the final hop is a successful response. A chain that ends in 404 redirected you faithfully to a missing page. The header checker on this site shows each hop and the final status together.
The codes that get confused with each other
| Code | What it means | What people assume |
|---|---|---|
| 200 | The server handled the request and returned a resource. | The page looks right. A 200 can be an error document, an empty app shell, or a login wall. |
| 401 and 403 | 401: credentials are missing or not valid. 403: the server understood you and is refusing. | They are the same “go away”. 403 is often a firewall, a bot rule, or file permissions. |
| 404 | Nothing exists at that address. | The whole site is down. The server is up; this path is not. |
| 429 | Too many requests. Back off and retry. | The application crashed. It is refusing volume, not failing the request itself. |
| 500 | The application threw an unhandled error. | It will pass. A 500 describes this request, not a planned maintenance window. |
| 502 and 504 | Both come from a proxy. 502: the app answered invalidly or not at all. 504: the proxy gave up waiting. | They are interchangeable. 502 usually means dead; 504 usually means stuck, often on a slow query. |
| 503 | The server is up and cannot handle the request right now: overload, maintenance, or a process that failed to start. | It is a 500 with a different name. A 503 implies the condition is temporary, which is why it should carry Retry-After when the duration is known. |
A 200 is not a rendered page
Header-only checks miss the failures visitors actually see: a broken script, a blocked asset, a certificate one browser rejects, a single-page app that returns 200 and then paints an error. If the page must contain a phrase — or must not contain “outage” — that is a keyword check on the body, which a status-code lookup will never do.
For a one-off answer, use the status check or the header checker on this site. Both call the same public endpoint, which follows redirects and returns the final status. The header checker adds the header list and the redirect chain. Neither watches the site tomorrow. A monitor does, on a schedule, and a failed check is re-checked from another region before an alert. On the free plan that schedule cannot be faster than every five minutes, and the regular check runs from one region.
curl -fsS https://api.hypermonitors.com/v1/tools/http \
-H 'content-type: application/json' \
-d '{"url":"https://example.com"}'The body is a URL and nothing else: no method, no headers, no request body. Public hostnames only. The endpoint is rate-limited, and a non-200 from curl itself (the -f flag) means the checker refused or failed, not that example.com returned an error.