Which HTTP codes count as downtime
Published . Updated .
This guide explains how an uptime check should read HTTP status codes, and how to test the monitor you have instead of assuming every tool agrees.
Most uptime monitors treat 2xx as up and 5xx, timeouts, and TLS failures as down. 3xx and 4xx are judgment calls: a redirect to a login page or a 403 from a bot challenge can hide a real outage. Decide per check and test what your monitor actually does.
RFC 9110 groups status codes by the first digit. 2xx means the server completed the request successfully. 3xx means the client must look somewhere else. 4xx means the server refused or could not understand this client. 5xx means the server failed while trying. Those are protocol facts. "Down" is a policy you lay on top of them. Two monitors can see the same 403 and file different incidents. Yours should be the one you can explain to a client.
What does each class mean for a check?
A 2xx, including 200 and 204, is the result you wanted if you asked for a public page. It does not prove the page is correct. A 200 with an error message in the body is still a 200. Keyword checks exist for that, and they are a separate decision. If you did not configure one, do not claim you measure page content.
A 3xx, including 301 and 302, means the URL you saved is not the final URL. Following a short chain of HTTPS redirects and then judging the last response is reasonable. Stopping on the redirect and calling it a failure is also a policy. A redirect to a parking page or to a login can hide the outage you thought you were watching. A redirect from http to https is normal, and a check that only speaks HTTPS may never see the http hop.
A 4xx is the muddy class. 404 and 410 mean the target is not there. For a URL you chose on purpose, that is down: the page you promised to watch is gone. 401 and 403 mean this client is not allowed. Your checker may be blocked, or the whole site may be blocking everyone. 408 means the server timed out waiting, which belongs with failures. 429 means you are being told to slow down. Paging a human because the checker was rude is a false alarm. The way to cut those is in false alarms.
A 5xx, including 500, 502, 503, and 504, means the service failed this request. Treat it as down unless you have a documented exception. A 503 with a retry-after header is still a failed request for a visitor who arrived just then.
Timeouts and TLS failures never produce a status code. The connection did not finish. Treat both as down. A TLS failure is also a certificate problem, which is the subject of the certificate checklist. A timeout is not a certificate verdict. You did not get far enough to have one.
| Class | Examples | A practical uptime policy |
|---|---|---|
| 2xx | 200, 204 | Up, unless you also required the origin and did not reach it |
| 3xx | 301, 302, 307 | Follow a short HTTPS chain, then judge the last hop. A leftover redirect is a configuration problem, not always an outage |
| 4xx not found or timeout | 404, 410, 408 | Down. The URL you watch is missing or the server gave up |
| Other 4xx | 401, 403, 429 | Do not call it an outage until you know the public is blocked too |
| 5xx | 500, 502, 503, 504 | Down |
| No status | Timeout, TLS error, network error | Down. TLS is a certificate problem. Timeout is not a trust verdict |
What about a redirect to a login or a challenge?
A public marketing URL that suddenly 302s to a staff login has changed. That can be a misconfiguration, a half-finished deploy, or the only URL you were given. Call it a failed measurement until someone decides the new target is correct. Do not silently follow it into a 200 on a login form and mark the store "up."
A 403 from a bot challenge is the CDN asking the checker to prove it is a browser. Visitors with a normal browser may be fine. The check failed to measure, which is different from the site being down. If you alert, the client will refresh, see the site, and trust you less. If you never alert, you will miss the day the challenge is shown to everyone. The middle path is a distinct state, "not measured," that a person can see and that does not page.
Test it. Curl the URL with the checker's user agent, and curl it with a browser's. If only the checker is challenged, write that down on the check.
What should you do on a check that behaves oddly?
Fetch the URL the way the monitor does, and read the status before you read the alert. If the code is a 403 or a 429, fix the allow rule or the rate limit, or accept a "not measured" state. If the code is a 301 to a new host, update the saved URL or follow the chain on purpose. If the code is a 200 and the user still says the site is down, you are measuring the edge or the wrong URL. Say so, and decide whether this check should require the origin.
- Decide 3xx and 4xx per check, and write the decision down.
- Treat 5xx, timeouts, and TLS failures as down.
- Treat a challenge and a 429 as "not measured" until you know visitors see them too.
- Test with the checker's user agent, not only with your browser.
- Keep classification and confirmation as two steps. One bad sample is not an incident yet.
The short names for these outcomes are in the glossary. Use them in the ticket so the next tech does not re-learn the table from a screenshot.
How The Watchbill helps
The Watchbill applies the policy in the table above, so you don't have to set it up site by site. Its checker identifies itself as TheWatchbill/1.0 (+https://thewatchbill.com), which makes it easy to find in your logs or allow through a firewall rule, and it gives up on a request after 10 seconds.
Timeouts, TLS failures, and network errors count as down, and so do 404, 410, 408, and any 5xx response. The checker follows up to four HTTPS redirects and judges the final response. A redirect that's still there after that is recorded as a redirect, not an outage. A 401, 403, or 429, or a bot-challenge page, is recorded as a measurement the site refused rather than an outage, so nobody is paged because a firewall blocked the checker. A 2xx counts as up, unless you turned on the origin check for that site and the origin didn't answer.
Classification is only the first step. A site is marked down or up only when two consecutive minutes agree, so one 500 doesn't open an incident by itself. If a site sits behind Cloudflare's proxy, a normal check measures Cloudflare's edge, and the origin check is a separate setting on that site. You can see how this works on your own sites with a free account.
Sources
- RFC 9110, HTTP Semantics, status codes. Accessed October 10, 2026.