Guides

HTTP status codes from a monitoring perspective: when is an alert justified?

Updated July 11, 2026 · 6 min read

Every HTTP response carries a three-digit status code, and for monitoring it is the single most important signal. But not every non-200 code is an emergency, and not every 200 means all is well. A practical overview.

Contents
  1. The system in 30 seconds
  2. The key codes in detail
  3. The trickiest case: soft 404s and empty pages
  4. Timeouts: the code that is not one
  5. Frequently asked questions

The system in 30 seconds

The first digit tells you the category: 2xx means success, 3xx redirection, 4xx client-side errors (the request is the problem), 5xx server-side errors (the server is the problem). The monitoring ground rule: 5xx is almost always alert-worthy; for 3xx and 4xx it depends on what you expect.

The key codes in detail

CodeMeaningMonitoring view
200OKThe expected value for most monitors. But: see soft 404 below.
301/302/308RedirectNormal (http to https, www variants). The monitor should follow redirects and judge the FINAL target; long chains cost load time.
401/403Unauthorized / forbiddenExpected behind login areas. If it suddenly appears on public pages: alert (broken config, WAF misfiring).
404Not foundAlways an error for a monitored URL: page deleted, route broken or incomplete deployment.
429Too many requestsRate limiting. If it hits your monitoring, the check interval is too aggressive or the limit too strict.
500Internal server errorAlert. Code bug, broken config, database problem.
502/504Bad gateway / gateway timeoutAlert. The reverse proxy cannot reach the application (process dead, deployment gap, overload).
503UnavailableAlert, unless it is a properly built maintenance page (503 + Retry-After is the clean way to signal maintenance).

The trickiest case: soft 404s and empty pages

A soft 404 is a response that technically says 200 but is broken in substance: an empty page, a generic error message, a maintenance template without the proper status code. Pure status-code monitors report "all fine" here.

The fix is a keyword check: it additionally verifies that an expected text (say, your company name in the footer or a product heading) appears in the response. Only status code AND content together add up to an honest "up".

Timeouts: the code that is not one

If the server does not respond at all, there is no status code, just a timeout or connection error. For monitoring this is the heaviest failure class, because it hits every visitor. Common causes: server down, broken DNS, firewall rules, or the application hanging under load. That is why response time belongs in monitoring alongside the status code: a page that climbs from 300 ms to 8 seconds usually announces its timeout in advance.

Frequently asked questions

Is pinging the server not enough?

No. Ping only proves the machine is on the network. Web server dead, database gone, certificate expired: the ping stays green. Only a full HTTP request against the real page is meaningful.

Is a 302 redirect an error?

By itself, no. What matters is where it leads: the monitor should follow the chain and judge the target. It becomes alert-worthy with redirect loops, or when a page suddenly redirects that never did.

What status code should my maintenance page return?

503 with a Retry-After header. That tells visitors, monitors and search engines the same thing: temporarily gone, please come back. A maintenance page returning 200 distorts monitoring and SEO alike.

Status code + content + response time, checked automatically.

Clesk Uptime checks all three, every 60 seconds on Pro. Three monitors free forever.

Monitor for free