HTTP status codes explained: what 200, 404, 502 mean for monitoring

In brief: An HTTP status code is a three-digit number the server responds with to every request. The group tells the category: 2xx = OK, 3xx = redirect, 4xx = client error, 5xx = server error. From the uptime monitoring perspective, we care most about 5xx and 4xx anomalies.

Response categories

• 1xx Informational - transient responses, the client usually doesn't notice.
• 2xx Success - the request succeeded. 200 OK is the default.
• 3xx Redirection - the client should go elsewhere. 301 permanent, 302 temporary.
• 4xx Client errors - the client sent something wrong. 404, 401, 403, 429.
• 5xx Server errors - the server failed. 500, 502, 503, 504.

2xx: success

200 OK - standard OK response. This is the "healthy" state you monitor for.

201 Created - typically a response to a POST that created a new resource. API clients expect it.

204 No Content - success but the server has nothing to return. DELETE endpoints often use it.

206 Partial Content - the server returned only part (range request). For video streaming or resumable downloads.

3xx: redirection

301 Moved Permanently - the URL changed permanently. Google transfers SEO equity to the new URL. Use during domain migration, transition from HTTP to HTTPS, switch to www/non-www.

302 Found / 307 Temporary Redirect - temporary redirect. Google doesn't move ranking. Use for A/B testing, maintenance, or when the URL will be back over time.

308 Permanent Redirect - like 301 but preserves the HTTP method (POST stays POST). 301 can be turned into GET by the client.

304 Not Modified - the client has cache, the server confirms the content hasn't changed. Saves bandwidth.

For monitoring: When checking 3xx responses configure whether the monitor should follow the redirect or treat it as an error. Some DNS hijack attacks manifest as unexpected 302.

4xx: client-side error

400 Bad Request - syntactic error in the request. Malformed JSON, missing header, etc.

401 Unauthorized - missing or bad credentials. The client must authenticate.

403 Forbidden - the client is authenticated but lacks permission. Watch out: some servers return 403 instead of 401 for security reasons (not revealing the resource exists).

404 Not Found - the URL doesn't exist. Doesn't matter for monitoring, but does for SEO (link equity leaks).

405 Method Not Allowed - the URL exists but doesn't accept the given method (e.g. POST to an endpoint that expects GET).

408 Request Timeout - the server waited for the request too long and closed the connection.

409 Conflict - the request conflicts with the current state (e.g. update of a version that's no longer current).

410 Gone - the resource was permanently removed. Better than 404 for Google (signal not to try to reindex).

422 Unprocessable Entity - the request is syntactically OK but contains semantically invalid data (failed validation).

429 Too Many Requests - rate limit. The client must slow down. The server typically adds the Retry-After header.

5xx: server-side error

500 Internal Server Error - generic error. The backend threw an exception the application didn't catch. Always alarm for monitoring.

501 Not Implemented - the server doesn't know the HTTP method (e.g. an old server doesn't support PATCH).

502 Bad Gateway - the reverse proxy (nginx, Cloudflare) didn't get a response from the backend server. Typically the backend crashed or timed out.

503 Service Unavailable - the server is overloaded or under maintenance. Often with a Retry-After header. This is a planned response, not a crash.

504 Gateway Timeout - the reverse proxy waited for the backend longer than the timeout. The backend is usually still running, just slow.

520-525 Cloudflare errors - specific to Cloudflare. 520 = backend returned something unreadable, 522 = backend didn't respond (connection timeout), 524 = backend responded too slowly (origin timeout).

Practical alerting rules

• Alert immediately: 500, 502, 503 (if not truly planned maintenance), 504, any timeout
• Alert on repetition: a one-off 5xx may be a race condition; alert if the same endpoint fails 2× in a row
• Watch upward trend: long-term growth in 4xx may mean broken link, scraper attack or broken frontend
• Ignore for alerting: 200-399 in the expected range (track response time instead of code)

Status code + response time = complete picture

Watching only the status code isn't enough - the server can return 200 but in 30 seconds, which from the customer's perspective is an outage. Quality monitoring combines:

1. Expected status code (typically 200)
2. Maximum response time (typically 5-10 seconds)
3. Keyword match in the content (a keyword that must be in the HTML)
4. SSL valid + not before the end of validity

Failure of any = alert.

Monitoring with precise error classification

ePulz.io distinguishes status code, response time, keyword match and SSL state. Logs for every check.

Try for 7 days →