HTTP Status Codes for Monitoring: Which Ones Mean Downtime

For monitoring, the codes that mean trouble are the 5xx range (server errors like 500, 502, 503, and 504) and an unexpected 4xx like 403 or 404 on a URL that should return content. A healthy check returns 200, and a 301 or 302 redirect is usually fine as long as it lands on a working page. The mistake most teams make is treating any non-200 as an outage: some 4xx codes are correct behavior, and some 200 responses hide real failures. The reliable rule is to alert on the specific codes that mean your service is broken, follow redirects to their destination, and also check the response body, because a page can return 200 while serving an error.

How HTTP status codes are grouped

Every HTTP response carries a three-digit status code, and the first digit tells you the category. For monitoring, you care less about memorizing all of them and more about knowing which category means "page me."

The 5xx codes that mean downtime

Server errors are the clearest signal that something is broken on your side, and they should always trigger an alert. These four are the ones you will see most.

• 500 Internal Server Error. The application crashed or threw an unhandled exception. A deploy that shipped a bug, a database that stopped responding, or a null that was not handled. Real outage, page someone.
• 502 Bad Gateway. A proxy or load balancer got an invalid response from the server behind it. Often your app process is down or restarting while the front-end proxy is still up. Real outage.
• 503 Service Unavailable. The server is overloaded or in maintenance mode and cannot handle the request. Sometimes intentional during a deploy, but to a customer it is downtime, so alert on it.
• 504 Gateway Timeout. A proxy waited for the upstream server and gave up. Usually a slow database, a stuck dependency, or a saturated server. Real outage, and often the first sign of a cascading failure. We break down the five causes of a 504 and how to fix each one separately.

If your monitor sees any 5xx from a URL that should be serving content, treat it as down. These are not ambiguous.

The 4xx codes that are trickier

Client errors are where naive monitoring gets noisy or misses real problems. A 4xx means the request was rejected, but whether that is a bug depends entirely on the URL.

• 404 Not Found. On a page that should exist, a 404 means something broke: a deploy removed a route, a rename was not redirected, or a CDN is misconfigured. On a random or deleted URL, a 404 is correct. Monitor the specific pages that must exist, and a 404 there is an alert.
• 403 Forbidden. On a public page, a 403 often means a firewall, a bot filter, or an expired credential is blocking access, which is a real problem for your users. Watch for it on pages that should be open.
• 401 Unauthorized. Expected on an authenticated endpoint if your monitor is not sending a token. If you are checking an API with valid credentials and suddenly get a 401, your auth broke, which is worth an alert.
• 429 Too Many Requests. You are being rate limited. If your own monitor triggers this, slow your check interval. If real users hit it, your limits may be too tight.

Why a 200 is not always healthy

The most dangerous failure in monitoring is the one that returns 200 OK. Plenty of applications answer with a success code while serving an error page, an empty result, or stale content. A server can render "Something went wrong" inside a page that technically returned 200, and a status-code-only monitor calls that healthy. This is why serious checks look past the code and inspect the response itself. Add a keyword or body assertion: confirm the page contains text that only appears when it is working, like a product name or a specific field in a JSON response. For an API, verify that the expected key exists and the value is sane, not just that a web server answered. We cover the full pattern in our guide on how to monitor an API.

The same trap shows up beyond a single request. An endpoint can return 200 with data that is technically present but hours out of date, which is why teams that depend on pipelines and feeds also watch the freshness and quality of the data behind them, not only the status code the endpoint returns. A green check that reports old numbers is its own kind of outage.

How should a monitor handle redirects?

A monitor should follow redirects to their final destination and check the status and content there, not treat the 301 or 302 itself as the answer. Redirects are normal: forcing HTTPS, sending a bare domain to www, or moving a page all produce a 3xx that ends at a working page. The failure mode to watch for is a redirect loop or a redirect that lands on an error, so configure your check to follow the chain and assert on the final response. One thing worth a dedicated check is that your canonical URL redirects correctly, because a broken HTTPS redirect can quietly break every visitor while each individual response looks valid.

Which HTTP status codes should trigger an alert?

Alert on every 5xx (500, 502, 503, 504) without exception, and on a 4xx only when it appears on a URL that should return content, such as a 404 or 403 on a live page. Treat 2xx as healthy only after a body or keyword assertion passes, and follow 3xx redirects to confirm the final page is good. In practice, the cleanest setup is to define the expected code per monitor (usually 200), treat anything else as a failure, and layer a content check on top so a 200 with a broken body still counts as down. That combination catches real outages while ignoring the redirects and expected client errors that would otherwise flood you with noise.

Turning codes into reliable alerts

Knowing which codes matter is only half the job; the other half is not paging people over transient blips. A single 502 during a brief restart is not an outage worth waking someone for, but three in a row from two regions is. The defense is confirmation: run checks from multiple regions, retry a failure from a second location before alerting, and only page when the bad code holds. That way a genuine 500 storm reaches you in seconds, while a one-off hiccup resolves itself silently. Route the real alerts to Slack, SMS, or a webhook, and feed the same up or down signal to your status page so customers see the incident without opening a ticket. Get that pipeline right and HTTP status codes stop being trivia and become a precise, low-noise early warning system for your whole stack. The 5xx you will meet most often is a bad gateway, so it is worth reading what a 502 Bad Gateway error means and how to fix it before you tune those thresholds.