HTTP Status Codes Through a Monitoring Lens — What Should Actually Page You

Every uptime check ultimately comes down to reading a three-digit number. The server answers 200 and your dashboard glows green; it answers 500 and someone's phone buzzes. Simple — until it isn't. Is a 301 fine? Is a 401 an outage or a feature? Should a 503 during your maintenance window really page the on-call at 2 AM? And what about the nastiest case of all — a page that returns a perfect 200 while showing your customers a stack trace?

Status codes are the vocabulary your site uses to tell your monitoring how it's doing, and treating them all as either "200 = good" or "anything else = bad" throws away most of the information. Here's a working taxonomy — which codes are healthy, which are configuration smells, which should page you, and where the number lies to you outright.

2xx: success, with caveats

• 200 OK — the expected answer for a normal page check. Healthy, if the body is actually your page (more on that below).
• 201 Created / 204 No Content — normal for APIs. If you're monitoring an API endpoint that correctly returns 204, your check must expect that, not 200 — an "is it exactly 200?" check marks a healthy API as down.
• A 2xx you didn't expect is worth a look. A 204 from a page that should serve HTML usually means something upstream is swallowing your response.

The rule: define the expected status per monitor, not one global notion of success.

3xx: fine in moderation, a smell in quantity

Redirects are part of a healthy site — http:// → https://, apex → www, old URLs to new. A monitor should follow them and judge the final response. But redirects deserve scrutiny:

• Assert the destination. Following redirects blindly means a misconfigured rule that bounces your checkout to the homepage still looks "up." Good checks assert where they landed, not just that they landed.
• Watch the chain length. http → https → www → trailing slash is four requests where one would do — each hop costs latency on every visit. More than one hop for a canonical URL is usually a config accident worth fixing.
• Redirect loops are a real outage: browsers give up with an error after ~20 hops. A monitor with a redirect limit catches the loop; one without hangs along with your visitors.
• A 301 is a promise. Permanent redirects get cached aggressively by browsers. If a monitor suddenly reports an unexpected 301 on a URL that should serve content directly, treat it as an incident — someone or something changed your routing.

4xx: usually a bug, occasionally a feature

4xx means "the client did something wrong" — but when the client is your own monitoring, it's your config that's wrong somewhere:

• 404 on a page that should exist deserves an alert as urgent as any 500. A deploy that dropped a route, a CMS page unpublished by accident — to the visitor it's identical to downtime. 404 on your homepage is a five-alarm incident.
• 401/403 can be correct — a check against an authenticated endpoint should get 401 without credentials, and asserting on that verifies your auth wall is up. The failure would be a surprise 200. Conversely, a sudden 403 on a public page often means a firewall or WAF rule started blocking legitimate traffic — including, possibly, your monitor (allowlist your monitoring provider's IPs or user-agent to keep the signal clean).
• 429 Too Many Requests from your own site to a well-behaved monitor usually means a rate limiter is misjudging real users too — worth investigating, not muting.

5xx: this is what paging was invented for

Server errors are the unambiguous ones — the server itself is telling you it failed:

• 500 Internal Server Error — an unhandled exception, on the record. Page someone.
• 502 Bad Gateway / 504 Gateway Timeout — your reverse proxy is up but the app behind it is crashed, hung or restarting. These often flap during failed deploys; confirmation before alerting keeps the signal honest, but sustained 502s are a hard outage.
• 503 Service Unavailable — the interesting one, because it's the only 5xx you'll ever send on purpose.

503 is the correct way to say "down for maintenance": it tells browsers and search engines alike that this is temporary — critically, search engines treat a 503 as "come back later" rather than deindexing the page, which is why a maintenance page served with 200 or 404 is an SEO own-goal. Pair it with Retry-After so well-behaved clients know when to return:

location / {
    return 503;
}

error_page 503 @maintenance;
location @maintenance {
    add_header Retry-After 3600 always;
    root /var/www/maintenance;
    rewrite ^ /index.html break;
}

And on the monitoring side: schedule a maintenance window so the planned 503 doesn't page anyone — while unplanned 503s (an overloaded backend shedding load) still do. Same number, opposite meanings; context is the difference.

The soft 200: when the number lies

The most dangerous responses in monitoring aren't error codes — they're 200s wrapped around failure:

• Error pages served with 200. Plenty of stacks render a pretty "something went wrong" page — database down, upstream API dead — and return it with 200 because nobody set the status. Status-code checks see nothing.
• Empty shells. A single-page app whose HTML loads (200!) while the JavaScript that renders literally everything is broken.
• Partial failure. The page loads; the "Add to cart" button doesn't. Revenue-zero, dashboard-green.

The defense is content assertions: require the response body to contain a string that only a working page has (product name, footer text, a known heading) — and, just as useful, require it not to contain the signatures of failure (Fatal error, Exception, "temporarily unavailable"). A keyword check converts "the server answered" into "the page actually works," which is what you cared about all along.

Teach your monitoring the whole vocabulary

Squint and the whole taxonomy compresses to four rules: expect specific codes per endpoint, follow redirects but assert the destination, page on 5xx except planned 503s, and never trust a bare 200. A monitor that can express those rules stops paging you for non-events — and stops sleeping through real ones.

CompleteStatus speaks the full language — per-monitor expected status codes, redirect following with final-URL awareness, keyword assertions to catch soft 200s, and maintenance windows so planned 503s stay silent. If you're newer to this, start with what uptime monitoring is, then create a free account and give your checks something smarter to assert than "was it 200?"