Which HTTP status codes should always trigger an alert?

All 5xx codes (500, 502, 503, 504) should alert, since they mean the server failed. In the 4xx range, alert selectively: a 403 or 404 spike after a deploy, 429 rate-limiting, and 404s on specifically monitored URLs. Treat baseline 4xx noise from bots as informational only.

Can a page return 200 and still be broken?

Yes. Single-page apps and CDNs frequently return HTTP 200 while rendering an error inside the body, and cached error pages can carry a 200 header. Add content assertions that check for an expected string in the response, so you catch failures that the status code alone hides.

How do I avoid alert fatigue from status code monitoring?

Use rate-based thresholds instead of single-event alerts. Trigger when the error rate on a route crosses a percentage over a rolling window, rather than on the first error. Set tight thresholds for critical endpoints and looser ones for pages where occasional errors are normal.

HTTP Status Code Monitoring: Which 4xx and 5xx Errors to Alert On

VigilDog Team · September 4, 2026 · 6 min read

A basic uptime check asks one question: did the server respond? That misses the failures that actually cost money. A page can return HTTP 200 while serving an error to users, a checkout endpoint can throw 500s while the homepage stays green, and a deploy can lock down a route with 403s that no ping ever notices. HTTP status code monitoring is the difference between knowing the server is on and knowing it is working.

"Is it up?" is the wrong question

Most simple monitors treat any response as success. But HTTP status codes are the server telling you precisely what went wrong, and the useful signal lives in which codes appear, on which routes, and how often. The goal of status code monitoring is not to alert on everything, a busy site throws 4xx errors constantly from bots and mistyped URLs, but to separate the codes that mean "a real user is blocked right now" from the ones that are ordinary background noise.

The practical split is by class. The 5xx range is the server admitting fault and almost always deserves attention. The 4xx range blames the request, so it needs judgment: some 4xx errors are your fault in disguise, and most are harmless.

5xx errors: alert on all of them

Server errors mean your infrastructure broke, not the client. Treat every one as actionable:

500 Internal Server Error, an unhandled exception in your application. Something threw and nobody caught it.
502 Bad Gateway, your reverse proxy or load balancer reached an upstream that returned garbage or crashed. Often a backend process that died.
503 Service Unavailable, the server is overloaded or in maintenance mode. Expected during a planned window; alarming otherwise.
504 Gateway Timeout, an upstream took too long to answer. Usually a slow database query or a hung dependency.
Any 5xx on a critical path (checkout, login, API) should page someone. On a marketing page it is lower urgency but still a bug.

4xx errors: alert selectively

Client errors are noisy by nature, so alerting on the raw count is a fast track to ignored alarms. Watch these with context instead:

The pattern that matters most is the sudden change. A 403 spike minutes after a deploy usually means a permission or config regression locked out real users. A 404 on a URL you explicitly monitor means a page that should exist has vanished. A wave of 429s means you are being rate-limited by an upstream or hammered by traffic. A steady trickle of 404s from crawlers hitting old links is not an incident and should never wake anyone.

401 Unauthorized / 403 Forbidden, a spike after a change signals a broken auth config or an over-tight firewall rule. Alert on the delta, not the baseline.
404 Not Found, noise in general, but a hard alert when it appears on a specific URL you have chosen to monitor.
429 Too Many Requests, you are being throttled. Worth an alert because it silently degrades real traffic.
400 Bad Request, usually a broken client or malformed automation; investigate only on a sustained spike.

The status codes that lie

Two failure modes slip past status-only monitoring entirely. The first is a 200 that serves the wrong thing: a single-page app that renders "Something went wrong" inside an otherwise successful response, or a CDN returning a cached error page with a 200 header. The fix is content assertion, check that the response body contains an expected string (a product name, a specific element) and alert when it disappears, even at 200.

The second is the redirect trap. A misconfigured rule can create a 301 or 302 loop, or redirect your login page to an error page. Monitors that follow redirects blindly report success; monitors that stop at the first hop miss the destination. Configure your check to follow redirects to a bounded depth and assert the final URL and status are what you expect.

Alert on rates, not single events

One 500 from a transient blip is not worth waking up for; fifty 500s in two minutes is an outage. The reliable pattern is threshold-over-window: alert when the error rate for a route crosses a percentage over a rolling interval, not on the first bad response. This suppresses flapping and still catches genuine failures fast. Pair it with a low threshold on truly critical endpoints, where even a handful of errors matters, and a higher tolerance on pages where the odd error is expected.

Status monitoring also pairs naturally with certificate and DNS checks, because the same deploy that returns a fresh 502 might also have shipped a broken redirect or an expiring cert. It is worth understanding how SSL monitoring differs from uptime monitoring so you cover both the transport layer and the response. Bundling status, latency, and certificate checks into one monitoring setup means a single alert points you at the real cause instead of three tools disagreeing.