HTTP Status Codes
HTTP status codes are the language that servers use to communicate the outcome of a request. A 200 means success, a 404 means the resource doesn't exist, and a 503 means the server is temporarily unavailable. Understanding status codes is essential for diagnosing problems and building reliable monitoring systems.
Definition
An HTTP status code is a three-digit number sent by a server in the response headers of an HTTP request. It indicates whether the request succeeded, failed, or requires further action. Status codes are grouped into five classes: 1xx (Informational), 2xx (Success), 3xx (Redirection), 4xx (Client Error), and 5xx (Server Error).
For example, when you visit a website, your browser makes an HTTP request. If the page exists and loads successfully, the server responds with 200 OK. If the page doesn't exist, you get 404 Not Found. If the server is down, you get 503 Service Unavailable.
The Five Classes of HTTP Status Codes
Every HTTP status code fits into one of five categories based on its first digit. Each category has a specific meaning:
1xx - Informational
The request was received and processing is continuing. These are rare in practice and you typically don't see them as a final response. Example: 100 Continue.
2xx - Success
The request succeeded. The server understood the request, processed it, and returned the expected result. Common codes: 200 OK, 201 Created, 204 No Content. For monitoring, 2xx responses indicate healthy services.
3xx - Redirection
The resource has moved or the request needs additional action to complete. Common codes: 301 Moved Permanently, 302 Found, 304 Not Modified. Browsers automatically follow redirects, but monitoring systems should verify redirect chains are correct.
4xx - Client Error
The request was malformed, missing authentication, or invalid. Common codes: 400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found. These usually indicate client-side issues, not service downtime.
5xx - Server Error
The server failed to fulfill a valid request. Common codes: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout. 5xx errors indicate service problems and should trigger alerts.
The Most Important Status Codes for Monitoring
While there are dozens of HTTP status codes, a handful are critical for monitoring systems. Here are the ones you should understand:
| Code | Meaning | Indicates | Action |
|---|---|---|---|
| 200 | OK | Request succeeded | ✓ Service is healthy |
| 201 | Created | Resource successfully created | ✓ Request succeeded |
| 301 | Moved Permanently | Resource permanently moved to new URL | ✓ Update URLs if needed |
| 302 | Found | Resource temporarily at different location | ✓ Follow redirect |
| 304 | Not Modified | Cached copy is still valid | ✓ Normal caching behavior |
| 400 | Bad Request | Request is malformed or invalid | ⚠ Check request format |
| 401 | Unauthorized | Missing or invalid authentication | ⚠ Check API key/credentials |
| 403 | Forbidden | Request is denied (insufficient permissions) | ⚠ Check user permissions |
| 404 | Not Found | Resource doesn't exist | ⚠ Check URL or delete endpoint |
| 429 | Too Many Requests | Rate limit exceeded | ⚠ Slow down requests |
| 500 | Internal Server Error | Server error (unhandled exception) | 🚨 Service is down |
| 502 | Bad Gateway | Gateway received invalid response from backend | 🚨 Upstream service down |
| 503 | Service Unavailable | Server temporarily unable to handle requests | 🚨 Service is down or overloaded |
| 504 | Gateway Timeout | Gateway didn't receive response from backend in time | 🚨 Service is slow or down |
Why Status Codes Matter for Monitoring
Status codes are the primary signal that monitoring systems use to detect problems. Here's why they matter:
Detecting Downtime
When a service is down, it returns 5xx status codes. A monitoring system that checks status codes can detect downtime within seconds. This is much faster than waiting for user complaints.
Identifying Root Cause
Different status codes indicate different problems. A 502 Bad Gateway suggests the issue is with an upstream service. A 503 Service Unavailable suggests the server is overloaded. A 404 Not Found suggests the endpoint was deleted. This helps your team diagnose faster.
Distinguishing Issues
A 401 Unauthorized error is not a service outage — it indicates an authentication problem. A 429 Too Many Requests indicates the API is rate-limiting. A 500 Internal Server Error indicates a bug. Smart monitoring systems understand these distinctions and alert appropriately.
Validating Application Logic
By checking that your endpoints return the expected status codes, you can validate that your application is working correctly. A health endpoint should always return 200. An API endpoint that's misbehaving might return unexpected 500 or 503 codes.
Common Status Code Patterns
When monitoring HTTP services, you'll encounter patterns that reveal different types of problems:
Repeated 5xx Responses
Indicates the service is down or experiencing a critical error. This should trigger an immediate alert to your on-call team. Examples: 500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable, 504 Gateway Timeout.
Many 4xx Responses (especially 401, 403)
Indicates authentication or permission issues. Your application might be running, but users cannot access it due to misconfigured API keys, expired credentials, or permission changes. Investigation needed, but not an immediate outage.
Sudden 404 Responses on Previously Working Endpoints
Indicates an endpoint was deleted or the routing changed. This is a regression that should be investigated. If 404s appear on health check endpoints specifically, the monitoring won't detect actual downtime.
Repeated 429 (Too Many Requests)
Indicates rate limiting is being enforced. If your monitoring checks are getting rate-limited, you're checking too frequently or the API's rate limits are too strict. Adjust check intervals or request higher rate limit quotas.
Best Practices for Status Code Monitoring
Follow these practices to get the most value from HTTP status code monitoring:
Monitor Health Endpoints Specifically
Create dedicated health check endpoints (like /health, /api/status) that return 200 when healthy and 5xx when unhealthy. This provides a single, authoritative signal for monitoring systems.
Alert on 5xx Responses, Not 4xx
5xx errors indicate service problems. 4xx errors are usually client-side issues. Your monitoring alerts should focus on 5xx responses to avoid false alarms from client errors.
Validate Response Body, Not Just Status Code
Some buggy services return 200 even when something is wrong. In addition to checking the status code, validate that the response body contains expected data. For example, check that a JSON endpoint returns valid JSON with the expected fields.
Use Multi-Region Checks
A single failed status code check might be a transient network issue. Require multiple regions to report failures before alerting. This reduces false alarms while still detecting real outages quickly.
Frequently Asked Questions
What are HTTP status codes?
HTTP status codes are three-digit numbers that indicate the outcome of an HTTP request. The first digit indicates the general category: 1xx (informational), 2xx (success), 3xx (redirection), 4xx (client error), or 5xx (server error). They are essential for both applications and monitoring systems to understand what happened to a request.
What does a 5xx status code mean?
A 5xx status code indicates a server-side error — the server received a valid request but cannot fulfill it. Common examples are 500 (Internal Server Error), 502 (Bad Gateway), 503 (Service Unavailable), and 504 (Gateway Timeout). When a monitoring system detects 5xx responses, it typically indicates the service is down or experiencing serious problems.
What's the difference between 4xx and 5xx errors?
4xx errors indicate a client-side problem — the request itself was invalid, missing credentials, or asking for a resource that doesn't exist. 5xx errors indicate the server couldn't process a valid request. For monitoring, 5xx errors represent actual outages, while 4xx errors usually indicate configuration issues or missing resources.
Why should I monitor HTTP status codes?
Status codes reveal different types of problems. A pattern of 403 (Forbidden) responses might indicate authentication issues. Repeated 404 (Not Found) errors suggest broken links or deleted endpoints. 5xx errors indicate downtime. By monitoring status codes, you can detect and diagnose problems faster than waiting for complete service failure.
What should a healthy HTTP status code be?
A 200 (OK) or 201 (Created) status code indicates the request succeeded. For redirects, 301 (Moved Permanently) or 302 (Found) are expected. Some APIs return 204 (No Content) for successful requests with no response body. Anything in the 2xx range generally means success, while anything outside that range suggests an issue.
Can I use response status codes for application health?
Yes, status codes are a primary health indicator. By checking the status code returned by a health endpoint (/health, /api/status), monitoring systems can determine service health. A 200 response indicates the service is up; a 5xx indicates it's down. Some monitoring systems also validate that the response body contains expected data.
What does a 429 (Too Many Requests) status code indicate?
A 429 response means the client has exceeded the rate limit for that API or service. Rate limits are implemented to protect servers from being overwhelmed. If your monitoring system receives frequent 429 responses, it may indicate legitimate traffic spike, a DDoS attack, or that your monitoring tool is not respecting the API's rate limits.
Definition
AtomPing monitors HTTP status codes from 10 European locations, alerting instantly on 5xx errors and unexpected status changes. Free forever plan includes 50 monitors.
Start Monitoring Free