HTTP Status Codes: Which Ones Should Page You

HTTP status codes are the first thing an external check reads, and most of them should never reach a pager. A monitor's job is to turn a three-digit number into one of three outcomes: wake someone, open a ticket, or record it and move on. Getting that mapping right removes more noise than any threshold you can tune afterwards.

The five classes, read the way a probe reads them

A probe cares about two questions. Did a response arrive at all, and does the code match what you asserted? MDN's status reference groups every code into five classes, and that grouping is still the fastest way to decide an alerting policy. The class tells you whose fault it is. The exact code tells you what to do next.

Class	What it means	Default monitoring action
1xx	Interim response	Ignore, a probe rarely sees one
2xx	Request completed	Assert the body too, not just the code
3xx	Client must follow	Assert the final destination
4xx	The request was wrong	Ticket, with three exceptions below
5xx	The server failed a valid request	Page, after a second region confirms

The registry behind those classes is public. IANA's status code registry maps each number to its defining section of RFC 9110, which is the source to cite when a team argues about semantics.

Which HTTP status codes should page you?

Page on 5xx and on no response at all. Everything else belongs in a ticket or a log line. A 500, 502, 503 or 504 from an endpoint that answered 200 an hour ago is the server admitting fault. No other class does that, which makes 5xx the cleanest paging signal you have.

Three client errors earn an exception. A 401 or 403 on a path that authenticated yesterday usually means a rotated key or an expired token, and that is an outage for every integration you own. A sustained 429 means a rate limit is now the binding constraint. A 404 on a URL that is still in your sitemap means something was deleted without a redirect.

The word "error" does a lot of work here. People search for http error codes and mean 4xx and 5xx together, but only one of those classes describes a server that broke.

Asserting on a code instead of eyeballing it

Assertions are where the policy stops being a table and starts being configuration. This monitor checks that an old URL still redirects to the right place. It is not satisfied by a URL that merely responds.

curl -X POST https://uptimeroom.com/api/v1/monitors \
  -H "Authorization: Bearer urm_live_..." \
  -H "Content-Type: application/json" \
  -d '{
    "name": "legacy guide redirect",
    "type": "http",
    "target": "https://example.com/old-guide",
    "intervalSec": 60,
    "followRedirects": false,
    "expectedStatus": [301]
  }'

With redirect following turned off, the probe reports the first code it receives. Turn it on and the probe reports the last one, which is what a browser would land on. Those are different tests, and you usually want both. To prove the destination still works, add a second monitor pointed straight at the new URL. The full field list is in the REST API reference.

The two responses that lie to you

A 200 is not proof that anything worked. A single-page app that fails to load its data still returns 200 with a shell document, and a misconfigured catch-all route answers 200 for URLs that no longer exist. The fix is a content assertion on top of the code, which is what keyword monitoring does.

Redirect chains are the second trap. We tested a marketing redirect that had quietly grown to four hops, and the final 200 came from a staging host. A status-only check had shown green for weeks, because the last response in the chain was perfectly valid. It was just valid on the wrong server.

Common mistakes

Accepting any 2xx. A 204 where you expected 200 means the response body vanished. Assert the exact number, not the class. Body assertions matter most on JSON endpoints, which is the core of API monitoring.

Paging on the first 5xx. One failed check from one region is a blip, not an incident. A second region has to agree first, the reasoning behind cross-region quorum confirmation.

Treating 429 as downtime. A rate limit is a capacity signal, not an outage. Graph it, raise a ticket, and only page if the successful path also starts failing.

Read the number, then decide who it belongs to. Most HTTP status codes belong in a backlog rather than on a phone. The ones that genuinely warrant waking someone fit on a single line: 5xx, no response, and a few authentication failures. You can encode that policy in a few assertions on the free plan, which covers 10 monitors at a 1-minute check interval as of September 2026.