HTTP Status Codes, Read Through a Monitoring Lens

The server received the request headers and the client should send the body.

In monitoring: Rarely seen by monitors. Not a terminal response — the check waits for the final status.

The server is switching protocols as requested, typically to WebSocket.

In monitoring: Expected when probing a WebSocket upgrade endpoint. Treat as healthy in that context.

Preload hints sent before the final response.

In monitoring: Informational only. Your monitor should grade the final status that follows.

The request succeeded and the response body contains the result.

In monitoring: The normal healthy state. Remember that 200 alone does not prove the body is correct — add a keyword assertion.

The request succeeded and a new resource was created.

In monitoring: Healthy for POST monitors. Be careful not to create real records on every check — use a synthetic account.

The request was accepted for processing but is not complete.

In monitoring: Healthy, but it only proves the queue accepted the job — not that the work succeeded.

The request succeeded and there is no body to return.

In monitoring: A common healthy response for health-check endpoints. Body assertions cannot be used here.

The server is delivering part of the resource due to a range request.

In monitoring: Healthy when probing range-capable endpoints such as media or large file downloads.

The resource has permanently moved to a new URL.

In monitoring: Usually fine if your monitor follows redirects. If unexpected, someone changed routing — investigate.

The resource temporarily resides at a different URL.

In monitoring: Common for auth redirects. A monitor that stops here without following may falsely report failure.

The response is at a different URL and should be retrieved with GET.

In monitoring: Typical after a POST. Follow redirects to grade the final destination.

The cached copy is still valid; no body is returned.

In monitoring: Healthy for conditional requests. Send no cache validators if you want the full body every check.

Same as 302 but the method must not change.

In monitoring: Follow it. Frequently used for HTTP-to-HTTPS enforcement.

Same as 301 but the method must not change.

In monitoring: Follow it. Consider updating the monitor URL to the final target to save a round trip.

The server could not understand the request due to malformed syntax.

In monitoring: Almost always a broken monitor configuration rather than a broken service. Check your payload.

Authentication is required and has failed or not been provided.

In monitoring: If unexpected, your monitor credentials expired. This is a very common cause of overnight false alarms.

The server understood the request but refuses to authorise it.

In monitoring: Often a WAF or bot filter blocking the probe. Allowlist your monitoring source before assuming an outage.

The requested resource does not exist on the server.

In monitoring: For a monitored endpoint this is a real failure — either the route was removed or a deploy broke routing.

The method is known but not supported for this resource.

In monitoring: Usually a misconfigured monitor sending GET where POST is required, or vice versa.

The server timed out waiting for the request.

In monitoring: Points to network trouble between probe and origin. Confirm from other regions before paging.

The resource is permanently gone with no forwarding address.

In monitoring: Intentional removal. Retire or repoint the monitor rather than leaving it alarming.

An April Fools joke code from RFC 2324 that stuck around.

In monitoring: Occasionally used by services to reject automated traffic. If you see it, you are being filtered.

The client has sent too many requests in a given window.

In monitoring: Your check interval may be too aggressive, or the probe IPs are being rate limited. Slow down or allowlist.

A generic error occurred and the server could not be more specific.

In monitoring: An unambiguous outage signal. This should always open an incident.

The server does not support the functionality required.

In monitoring: Rare in production. Usually indicates a proxy that does not understand the method being sent.

A gateway or proxy received an invalid response from the upstream server.

In monitoring: Classic sign the application behind the load balancer is down or restarting. Page on this.

The server is temporarily unable to handle the request, often due to overload or maintenance.

In monitoring: Real user impact. Distinguish planned maintenance windows so they do not count against your SLA.

A gateway did not receive a timely response from the upstream server.

In monitoring: The app is alive but too slow to answer. Usually a database or downstream dependency problem.

The server cannot store the representation needed to complete the request.

In monitoring: Disk pressure. Frequently precedes a total failure — treat as urgent even if the site still loads.

The server detected an infinite loop while processing the request.

In monitoring: Configuration error, commonly a redirect or symlink cycle. Requires a fix, not a retry.

A Cloudflare-specific code meaning the origin refused the connection.

In monitoring: The CDN is healthy but your origin is not answering. Check the origin host directly.

A Cloudflare-specific code meaning the origin did not answer in time.

In monitoring: Often a firewall dropping CDN traffic, or an origin saturated beyond its accept queue.