HTTP Status Codes for Uptime Monitoring: 200, 301, 401, 403, 429 and 5xx

Why status codes matter

HTTP monitors often begin with the response code because it is a compact description of what happened at the protocol layer. The correct interpretation depends on what the endpoint is supposed to do.

Common groups

2xx responses usually indicate success. 3xx responses represent redirection. 4xx responses generally point to a client or authorization problem. 5xx responses indicate a server-side or upstream failure. Monitoring policy should reflect the endpoint's purpose rather than blindly flag every non-200 response.

Why 401, 403 and 429 need context

A protected endpoint may correctly return 401 until credentials are supplied. A 403 can be an intentional authorization rule or a security layer response. A 429 can mean the service is reachable but rate-limited. These should not automatically be treated like a dead server.

Why 200 still does not prove application health

A service can return 200 with an error page, stale content, or a failed application state. Content checks and API payload checks can add another layer of validation.

Use a monitoring policy that matches the endpoint

Define what healthy means for each monitor. Then configure the check to test that definition instead of relying on a generic “must be 200” rule.