HTTP Status Codes and What They Mean for Uptime Monitoring

When an uptime monitor checks your endpoint, it does not read the response body. It reads the status code. That three-digit number is the primary signal your monitoring tool uses to decide whether your service is healthy, degraded, or down.

Understanding what each code means — and more importantly, what it means in the context of monitoring — is what separates a well-tuned alert setup from one that either pages you for nothing or stays silent during a real outage. This guide walks through every HTTP status code family with that lens in mind.

1xx — Informational

1xx codes are provisional responses. The server is telling the client: "I received your request, keep going." They are part of the handshake, not the outcome.

The two you will occasionally encounter are 100 Continue (the server is ready to receive the request body) and 101 Switching Protocols (used when upgrading from HTTP to WebSocket, for example).

For monitoring: You will almost never see a 1xx as the final response to a synthetic monitoring request. HTTP clients handle these transparently before the final response arrives. They are safe to ignore in your alert configuration.

2xx — Success

2xx codes mean the request was received, understood, and accepted. These are the codes your monitor wants to see.

• 200 OK — The standard success response. The request succeeded and the body contains the result. The vast majority of your GET endpoints should return this under normal conditions.

• 201 Created — A resource was successfully created, typically in response to a POST request. If you are monitoring a write endpoint, this is your healthy signal.

• 204 No Content — The request succeeded but there is nothing to return. Common on DELETE endpoints and some PUT operations. A monitor that expects a 200 and receives a 204 may incorrectly flag this as an error — make sure your monitor accepts both if your endpoint uses both.

• 206 Partial Content — The server is returning only part of the resource, in response to a range request. Relevant if you are monitoring a media streaming endpoint or a file download API.

Important caveat: A 200 does not guarantee your service is healthy. Some APIs return 200 OK with an error message in the body — for example, {"error": "database unavailable"}. Status-code-only monitoring will not catch this. If you own the API, design it to return appropriate non-2xx codes when something is genuinely wrong.

3xx — Redirection

3xx codes mean the resource has moved, either permanently or temporarily. The client needs to make a follow-up request to a different URL.

• 301 Moved Permanently — The resource has a new permanent URL. Browsers and most HTTP clients cache this redirect. If your monitor sees a 301, it likely means the URL you are monitoring is outdated.

• 302 Found — Temporary redirect to a different URL. The original URL is still valid for future requests. Common in login flows and short-lived redirects.

• 304 Not Modified — The resource has not changed since the client last fetched it (validated via ETag or Last-Modified headers). Synthetic monitors typically do not send cache validation headers, so you are unlikely to see this in practice.

• 307 Temporary Redirect — Like 302, but the client must use the same HTTP method on the redirected URL. Important for POST requests that should not silently become GETs.

• 308 Permanent Redirect — Like 301, but preserves the original HTTP method. The permanent version of 307.

For monitoring: The critical question is whether your monitoring tool follows redirects. If it does, it will report the final destination's status code — which is usually what you want. If it does not, a 301 or 302 will be reported as the result, which could hide a broken destination. Check your tool's redirect behaviour and configure it explicitly. A 301 on a URL you expect to return 200 is worth investigating — it often means a misconfigured domain, an expired SSL certificate redirect, or an unintended HTTP-to-HTTPS redirect that has not been updated at the monitor level.

4xx — Client Errors

4xx codes mean the server understood the request but refused or could not process it due to something on the client's side. This is the most nuanced family for monitoring, because "client" in this context often means your monitor itself.

• 400 Bad Request — The request was malformed. If your monitor is hitting a POST endpoint and receiving 400s, the request body or headers you configured are likely invalid. Fix the monitor, not the server.

• 401 Unauthorized — Authentication is required and was not provided or was invalid. If you are intentionally monitoring a public endpoint that should not require auth, a 401 means something changed on the server. If you configured auth credentials in your monitor, they may have expired.

• 403 Forbidden — The server knows who you are but will not let you access this resource. This can happen if the server's IP allowlist does not include your monitoring provider's IP range. It is worth checking whether you need to allowlist your monitor's source IPs.

• 404 Not Found — The URL does not exist. Either the resource was deleted, moved without a redirect, or the monitor is pointing at the wrong URL. Always alert on unexpected 404s — they often signal broken deployments where a route was accidentally removed.

• 408 Request Timeout — The server timed out waiting for the client to send the full request. Less common in synthetic monitoring, but worth noting — if you see these, it may indicate network instability between the monitor and your server.

• 429 Too Many Requests — Your monitor is being rate-limited. This is a monitoring-specific trap: your service is technically healthy, but your monitor is hitting it so frequently that the rate limiter kicks in. If you see consistent 429s, either reduce your check frequency or add your monitoring source IP to a rate-limit allowlist on your server.

For monitoring: Unlike 5xx errors, 4xx errors are almost always caused by the requester, not the server. Before alerting on a 4xx, ask: is this a monitor misconfiguration, or a genuine server-side change? The exception is 404 — an unexpected 404 on a previously healthy endpoint is a real signal worth alerting on.

5xx — Server Errors

5xx codes mean the server failed to fulfil a valid request. These are the codes that should immediately get your attention. Unlike 4xx errors, 5xx errors are unambiguously the server's problem.

• 500 Internal Server Error — Something went wrong on the server and it does not know how to be more specific. This is the generic catch-all for unhandled exceptions, crashed processes, and unexpected states. Any 500 from a production service warrants investigation.

• 502 Bad Gateway — A proxy or load balancer received an invalid response from an upstream server. Common when your application server crashes and the reverse proxy (nginx, Caddy, a cloud load balancer) cannot reach it. A 502 usually means your app process is down, not just slow.

• 503 Service Unavailable — The server is temporarily unable to handle the request, typically due to overload or scheduled maintenance. If you see 503s outside a known maintenance window, your service is likely under unexpected load or a worker pool has exhausted.

• 504 Gateway Timeout — A proxy or load balancer did not receive a timely response from an upstream server. The upstream is alive but too slow. This is different from a 502 — the app process is running, but it took too long to respond. Often caused by slow database queries, downstream API dependencies, or resource contention under load.

For monitoring: Alert on all 5xx codes. A single 5xx can be a transient blip, but consecutive 5xx responses — say, three or more in a row — almost always indicate a real outage. Configure your alerts to trigger on consecutive errors rather than isolated ones to reduce false positives while still catching real incidents quickly.

Alert Strategy: A Quick Reference

Here is a summary of how to approach each code family in your monitoring configuration:

Tools like Latency Test let you configure alerts based on both consecutive errors and error rate thresholds, so you can tune sensitivity per endpoint — a strict consecutive-error alert for your payment API and a more lenient rate-based alert for a lower-criticality endpoint.

Wrapping Up

Status codes are not just metadata — they are the clearest signal your service can give about its own health. 5xx codes demand immediate attention. 4xx codes usually point to a misconfigured monitor, with 404 being the notable exception. 3xx codes are worth understanding so your monitoring tool handles them correctly. And 2xx is what you are aiming for, with the caveat that a healthy status code does not always mean a healthy response body.

Getting your alert thresholds right — alerting on the right codes, ignoring the noise — is what makes an on-call rotation sustainable. Start with "alert on consecutive 5xx, investigate everything else," and refine from there as you learn your service's normal behaviour.