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

Response categories

• 1xx Informational - transient responses, the client usually doesn't notice them.
• 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 - the 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 of the resource (range request). Used for video streaming or resumable downloads.

3xx: redirection

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

302 Found / 307 Temporary Redirect - a temporary redirect. Google does not move ranking. Use it for A/B testing, maintenance, or when the URL will come back over time.

308 Permanent Redirect - like 301, but preserves the HTTP method (POST stays POST). With 301, the client may turn the request into a GET.

304 Not Modified - the client has a cache, and 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 show up as unexpected 302 responses.

4xx: client-side error

400 Bad Request - a syntactic error in the request. Malformed JSON, a missing header, and so on.

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 that the resource exists).

404 Not Found - the URL doesn't exist. For uptime monitoring of tracked pages, a 404 is an alert (the page vanished); random 404s from outside visitors are more of an SEO problem (link equity leaks away).

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

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

409 Conflict - the request conflicts with the current state (e.g. updating a version that is no longer current).

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

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 a Retry-After header.

5xx: server-side error

500 Internal Server Error - a 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) got no 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-526 Cloudflare errors - specific to Cloudflare. 520 = the backend returned something unreadable, 522 = the backend didn't respond (connection timeout), 524 = the backend responded too slowly (origin timeout), 525 = SSL handshake failed, 526 = invalid SSL certificate.

Practical alerting rules

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

Status code + response time = the full picture

Watching only the status code isn't enough - the server can return 200 but take 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 and not near expiry

Failure of any one = alert.

1xx: the codes you rarely see

The informational class is mostly invisible because libraries handle it for you, but two are worth knowing: 100 Continue - the client sent an Expect: 100-continue header before a large body; the server replies 100 to say "go ahead, send it". Useful for avoiding a wasted upload when the server would have rejected it on headers alone. 101 Switching Protocols - the response to a successful WebSocket upgrade. If you monitor a WebSocket endpoint over plain HTTP and expect 200, you will get a confusing result: a healthy WS server answers the handshake with 101, not 200.

Reading a code as a diagnosis

A status code is a starting point, not a verdict. The same code can mean very different things depending on context:

When a code surprises you, reproduce it from the command line: curl -sS -o /dev/null -w "%{http_code} %{time_total}s\n" https://example.com/path. That prints the code and the total time, which together usually point straight at the cause. Our HTTP status checker does the same thing from outside your network, which rules out "it works on my machine".

HEAD vs GET for monitoring

A HEAD request returns the same status and headers as GET but no body, so it is cheaper. It is tempting to monitor with HEAD to save bandwidth. The catch: some frameworks and CDNs handle HEAD differently from GET (or do not implement it at all and return 405), so a HEAD check can pass while real GET traffic is broken, or fail on a server that is perfectly healthy for browsers. For uptime monitoring, prefer GET so you exercise the same path your visitors do, and add a keyword check on the body that HEAD cannot give you.

Redirect chains and the SEO cost

Redirects are correct in isolation but expensive in chains. A request that goes http://site to https://site to https://www.site to https://www.site/ is four round trips before the page even starts loading, and every hop is a chance for one link to break. Google follows a limited number of hops before giving up. Best practice: - Collapse chains to a single 301 wherever possible (go straight to the final canonical URL). - Use 301/308 for permanent moves so ranking transfers; reserve 302/307 for genuinely temporary cases. - After any URL migration, crawl your own redirects and confirm each ends in a single 200, not another redirect or a 404. A monitor configured to not follow redirects will flag an unexpected 301 the moment it appears - which is exactly what you want when a misconfigured deploy suddenly starts bouncing your homepage somewhere new.

Monitoring with precise error classification

ePulz.io distinguishes status code, response time, keyword match and SSL state. Detailed logs are available for every check.

Try for 7 days →