HTTP Status Codes Explained: What Every Code Means for Your Monitoring

When your monitoring alerts fire, the first thing you see is an HTTP status code. Understanding what each code means — and more importantly, what caused it — is the difference between a 2-minute fix and a 2-hour investigation.

The Five Classes

For monitoring purposes, 5xx codes are always your problem, 4xx codes are usually not (but worth tracking), and 3xx codes need careful handling.

Success Codes (2xx)

200 OK

The request succeeded. This is what you want to see.

Monitoring note: A 200 response doesn't guarantee the page is correct. Always combine HTTP status checks with keyword monitoring — a 200 response with a PHP error message or blank page is still broken.

201 Created

The resource was successfully created (common for POST requests to APIs).

Monitoring note: If you're monitoring API write operations, expect 201, not 200.

204 No Content

Success, but no response body. Common for DELETE requests and health check endpoints.

Monitoring note: Some health endpoints return 204. Make sure your monitoring accepts this as "healthy."

Redirection Codes (3xx)

301 Moved Permanently

The resource has permanently moved to a new URL.

Monitoring note: Your monitoring should follow redirects (most tools do by default). But alert if the number of redirects changes — a redirect chain (301 → 301 → 301) is a performance problem and possible misconfiguration.

Common causes: - HTTP to HTTPS redirect (normal) - www to non-www redirect (normal) - Old URL to new URL (normal, if intentional)

302 Found (Temporary Redirect)

The resource is temporarily at a different URL.

Monitoring note: Often used incorrectly instead of 301. If you see a 302 where you expect content, it might mean the user is being redirected to a login page (authentication issue) or maintenance page.

304 Not Modified

The cached version is still valid.

Monitoring note: This is normal and good — it means caching is working. Don't alert on 304s.

307 / 308 (Temporary / Permanent Redirect)

Same as 302/301 but preserves the HTTP method (POST stays POST).

Monitoring note: Treat the same as their 302/301 equivalents.

Client Error Codes (4xx)

400 Bad Request

The server can't understand the request due to invalid syntax.

Monitoring note: Usually a client-side issue (malformed request). But a sudden spike in 400s after a deployment might mean you broke your API contract.

When to alert: Error rate > 5% of total requests (indicates possible API change).

401 Unauthorized

Authentication required but not provided or invalid.

Monitoring note: Expected for protected endpoints without credentials. But if your authenticated API endpoint starts returning 401 to valid tokens, your auth system is broken.

When to alert: 401 on endpoints that should accept valid auth tokens.

403 Forbidden

The server understood the request but refuses to authorize it.

Monitoring note: Could indicate: - IP blocking (firewall, WAF) - Permission misconfiguration - Rate limiting (some implementations use 403 instead of 429) - CORS issues

When to alert: Unexpected 403 on public endpoints.

404 Not Found

The requested resource doesn't exist.

Monitoring note: Normal for invalid URLs. But watch for: - Broken internal links (link rot) - Missing assets (CSS, JS, images) - Recently deleted or renamed pages - SEO issues (Google crawling dead URLs)

When to alert: 404 on URLs that should exist (your main pages, API endpoints).

405 Method Not Allowed

The HTTP method isn't supported for this URL (e.g., POST to a GET-only endpoint).

When to alert: Always — indicates a routing or configuration problem.

408 Request Timeout

The server timed out waiting for the client to send the request.

When to alert: High volume indicates network issues or server overload.

429 Too Many Requests

Rate limiting in action.

Monitoring note: This is your rate limiter working correctly. But track the volume: - Low volume: normal protection against abuse - High volume from legitimate IPs: rate limits too aggressive - Sudden spike: possible DDoS or bot attack

When to alert: Legitimate users getting rate limited (indicates limit needs adjustment).

Server Error Codes (5xx) — Always Alert

500 Internal Server Error

A generic "something went wrong" on the server.

Common causes: - Unhandled exception in application code - PHP fatal error - Misconfigured server - Application crash

Troubleshooting: 1. Check application error logs 2. Look for recent deployments 3. Check for resource exhaustion (memory, connections) 4. Check for dependency failures (database, external APIs)

502 Bad Gateway

The server acting as a proxy received an invalid response from the upstream server.

Common causes: - Application crashed / not running - Application starting up (not ready yet) - Proxy timeout (upstream took too long) - Wrong proxy configuration

Troubleshooting: 1. Check if the application process is running 2. Check application logs for crashes 3. Verify proxy configuration (nginx, Apache, load balancer) 4. Check if upstream is responding on the expected port

503 Service Unavailable

The server can't handle the request (usually temporary).

Common causes: - Server overloaded (too many connections) - Application in maintenance mode - Deployment in progress - Resource exhaustion (CPU, memory, connections) - Kubernetes pod not ready

Troubleshooting: 1. Check server resource utilization 2. Check if you're in maintenance mode 3. Look for deployment activity 4. Check connection pool / worker count

504 Gateway Timeout

The proxy didn't receive a response from the upstream server in time.

Common causes: - Slow database queries - External API timeout - Long-running request processing - Network issues between proxy and application

Troubleshooting: 1. Check database slow query log 2. Check external API response times 3. Look for long-running requests in application logs 4. Check network connectivity between proxy and app

520-527 (Cloudflare-Specific)

Cloudflare uses custom 5xx codes for various origin server issues:

Monitoring Configuration by Status Code

Conclusion

HTTP status codes are your monitoring system's language. Learn to read them fluently, and you'll diagnose issues faster, reduce false alerts, and build monitoring rules that catch real problems while ignoring noise. The key principle: 5xx is always your problem, 4xx is usually not (but worth watching), and 2xx with wrong content is the sneakiest failure of all.