HTTP Status Codes: Complete Reference for Monitoring Engineers

HTTP status codes are three-digit numbers that a server sends in response to each request. For most developers, this means 200 OK and occasionally 404. But if you're responsible for uptime, each code is a signal that requires a decision. A 502 at 3 AM and a 503 at 3 AM are two completely different incidents with different runbooks.

Below are all HTTP status codes from a monitoring and operations perspective: what each code means, when to alert, and when it's normal behavior. Each code comes with a runbook and practical recommendations.

How to Read HTTP Status Codes

The first digit defines the response class. This is the most important thing to remember:

2xx — success codes

200 OK

The most desired code in monitoring. Request processed, response received, everything works. When you set up HTTP monitoring, 200 OK is exactly your main health indicator.

But there's a nuance: 200 OK doesn't guarantee that the application works correctly. A page might return 200 with an empty body or with an error message inside HTML. That's why advanced monitoring systems support keyword checks — checking response content, not just status code.

201 Created

Resource created. Typical for POST requests to an API. If you monitor an API endpoint for creating records and receive 201 — it means the write path works. Useful for API monitoring.

204 No Content

Request successful, but no response body. Common response for DELETE requests and health check endpoints. If your /health endpoint returns 204 instead of 200, make sure your monitoring treats this code as "success".

3xx — redirects

301 Moved Permanently

Resource moved permanently. Browsers cache 301 aggressively — if you mistakenly set a 301, reverting will be painful. In monitoring context: if your site started returning 301 instead of 200 on the main URL — check nginx/Caddy configuration. Often this is a symptom of incorrect HTTP to HTTPS redirect or www to non-www redirect.

302 Found / 307 Temporary Redirect

Temporary redirect. Difference between 302 and 307: with 307 the request method is preserved (POST remains POST), with 302 — the method might change to GET. For monitoring it usually doesn't matter, but if you check API endpoints with POST requests, 307 is more correct.

308 Permanent Redirect

Same as 301, but request method is preserved. Used less often, but gaining popularity in REST APIs. In monitoring it's treated the same as 301.

Monitoring advice: most tools by default follow redirects and check the final status code. This is convenient, but masks problems: if your site suddenly starts returning a chain of 5 redirects — response time will grow, and monitoring will show green 200. Set up tracking response time with thresholds to catch such degradations.

4xx — client errors

400 Bad Request

Server didn't understand the request. Usually — invalid JSON in the body or missing required parameter. If your health check endpoint starts returning 400, check if the request format changed after deployment.

401 Unauthorized

No authentication. A common cause of false alerts in monitoring: API key or JWT token expired, and checks start failing with 401. If you monitor protected endpoints — make sure credentials haven't expired. AtomPing supports Bearer tokens and Basic Auth directly in HTTP check settings.

403 Forbidden

Authenticated but no access. In monitoring this often means: WAF blocked the monitoring IP, or a geo-restriction blocked the check region. If you're monitoring from multiple regions and getting 403 only from one — likely a problem with regional firewall rules.

404 Not Found

Resource not found. Second most common code after 200. For monitoring, 404 is a warning signal: someone deleted an endpoint, renamed the URL, or broke routing after deployment. Set up keyword checks on important pages — if instead of content you get "Page Not Found", monitoring will catch it even with 200 OK (some frameworks return a custom 404 page with code 200).

429 Too Many Requests

Rate limit. You're sending too many requests. In monitoring, this is a double-edged sword: if your monitoring itself gets 429 — reduce check frequency. If your users get 429 — you're rate limiting too aggressively. The Retry-After header suggests when to retry.

5xx — server errors (red alert)

Five-hundred codes — this is exactly why monitoring exists. Every 5xx code means: your server couldn't process a valid request. Users see an error, and you lose money, trust, and everything else.

500 Internal Server Error

Generic "something broke". Unhandled exception in code, database error, memory overflow — all this often causes 500. This is the most common 5xx code and the main trigger for incident management. If you see a 500 — first check the application logs.

502 Bad Gateway

Proxy (nginx, Caddy, AWS ALB) got an invalid response from upstream. In practice this almost always means one of two things: the application crashed (process not running), or the application hung and didn't respond in time. 502 is one of the most common codes during deploy: the new container didn't start, and the old one is already killed.

Runbook for 502: Check that the application process is running. Check the port — is the application listening on the port that nginx proxies to? Check nginx logs for "upstream prematurely closed connection". If 502 appears after deployment — add a health check to your orchestrator so traffic only goes to ready containers.

503 Service Unavailable

Server is temporarily unable to handle the request. Unlike 502, here the server is alive and intentionally saying "I'm busy". Typical scenarios: planned maintenance, overload (all workers busy), circuit breaker triggered.

If you're setting up maintenance mode — return exactly 503, not 200 with "under maintenance" text. Monitoring correctly recognizes 503 as downtime and counts it in SLA reports.

504 Gateway Timeout

Proxy didn't receive a response from upstream. Difference with 502: with 502 a response came but was invalid. With 504 — no response arrived within the timeout. 504 usually means: database hung on a heavy query, external API not responding, or a deadlock.

Runbook for 504: Increase proxy_read_timeout in nginx as a temporary solution. Then investigate slow requests: enable slow query log in PostgreSQL, check APM traces, or logs with response times. 504 often correlates with load increase — check CPU and memory on servers.

520–530 (Cloudflare-specific)

If you use Cloudflare, you'll see codes 520-530. These are not standard HTTP codes — Cloudflare created them for more detailed diagnostics. 520 means "unknown error" (origin returned something unclear), 521 — "web server is down" (origin not accepting connections), 522 — "connection timed out" (TCP connection to origin couldn't establish), 523 — "origin is unreachable", 524 — "a timeout occurred" (origin connected, but didn't respond within 100 seconds).

These codes are especially important when monitoring from external locations: your uptime monitor will see Cloudflare's code, not your origin's code. Don't confuse 522 (TCP connection problem to origin) with 504 (HTTP timeout problem).

How to set up monitoring HTTP status codes

Just checking "site responds" — is not enough. Here's what you should monitor:

Complete HTTP status codes table

For quick reference — complete table with description and severity level for monitoring.

Common mistakes in monitoring HTTP codes

Monitor only the homepage. Homepage might be on CDN and work even with a dead backend. Add checks for API endpoints, login page, checkout flow — places that depend on database and backend services.

Ignore 3xx. One redirect — normal. A chain of 5 redirects — 2-3 seconds of load loss and a reason to investigate. Some CDNs create redirect loops with improper configuration — monitor this too.

Don't check response body. 200 OK with text "Database connection failed" — this isn't success. Use keyword monitoring to check content.

Single region monitoring. Your site might return 200 from Europe and 503 from Asia. Multi-regional monitoring catches these problems before users start complaining.