HTTP status codes are three-digit numbers a server sends back with every response. The first digit tells you the class of response. The next two digits narrow it down.
This guide covers every meaningful status code - what it means, when you'll encounter it, what to do when your monitoring catches it, and which ones matter most for reliability.
Status Code Classes
| Class | Range | Meaning |
|---|---|---|
| 1xx | 100–199 | Informational - request received, processing continues |
| 2xx | 200–299 | Success - request received, understood, and accepted |
| 3xx | 300–399 | Redirection - further action needed to complete request |
| 4xx | 400–499 | Client error - request contains bad syntax or can't be fulfilled |
| 5xx | 500–599 | Server error - server failed to fulfill a valid request |
The dividing line at 4xx vs. 5xx matters for monitoring: a 4xx means the client did something wrong; a 5xx means the server failed. When your uptime monitor fires on a 4xx, check your monitor configuration. When it fires on a 5xx, check your infrastructure.
1xx - Informational
These codes acknowledge the request is in progress. You rarely encounter them in standard HTTP/1.1 flows, but they appear in HTTP/2 push scenarios and WebSocket upgrade handshakes.
| Code | Name | Meaning |
|---|---|---|
| 100 | Continue | The server received the request headers and the client should proceed with sending the request body. Used when the client sends Expect: 100-continue before a large upload. |
| 101 | Switching Protocols | The server agrees to upgrade the connection protocol. Most commonly seen in WebSocket upgrades (Upgrade: websocket). |
| 102 | Processing | The server received the request and is processing it, but hasn't finished. Prevents the client from timing out during long operations. (WebDAV) |
| 103 | Early Hints | The server sends preliminary response headers (e.g., Link: rel=preload) before the final response. Allows browsers to start preloading assets early. |
Monitoring relevance: 101 appears in WebSocket health checks. 103 is a CDN optimization feature. You won't monitor against 1xx codes in standard uptime monitoring.
2xx - Success
The request was received, understood, and processed. The specific 2xx code tells you how it was processed.
| Code | Name | Meaning |
|---|---|---|
| 200 | OK | Standard success. The response body contains the requested data. |
| 201 | Created | A new resource was created. Typically returned after a successful POST. The Location header usually points to the new resource. |
| 202 | Accepted | The request was accepted for processing, but processing hasn't completed. Used for async operations where the server queues work. |
| 203 | Non-Authoritative Information | The response comes from a third-party proxy, not the origin server. The body may differ from what the origin would have returned. |
| 204 | No Content | The request succeeded but there's nothing to return. Common in DELETE operations, OPTIONS preflight responses, and PATCH calls where no body is needed. |
| 205 | Reset Content | Success, and the client should reset the document view (e.g., clear a form). Rarely used in practice. |
| 206 | Partial Content | The server is delivering only part of the resource. Used for range requests - resumable downloads, video streaming, large file chunking. |
| 207 | Multi-Status | The response body contains multiple status codes for multiple sub-requests. (WebDAV) |
| 208 | Already Reported | Resources have already been listed in a previous response. Prevents infinite loops in DAV tree traversal. (WebDAV) |
| 226 | IM Used | The server fulfilled a GET request using delta encoding. (HTTP Delta Encoding, RFC 3229) |
2xx codes you'll encounter most
200 OK - 95%+ of successful responses. Configure your monitors to expect 200 from health check endpoints.
201 Created - Verify your API returns this after POST requests that create resources. If your API returns 200 on creation instead of 201, it works but doesn't follow REST conventions.
204 No Content - Common from DELETE endpoints and webhooks. If your uptime monitor checks a DELETE endpoint and expects a body, 204 will look like a failure. Configure body checks carefully on these endpoints.
206 Partial Content - Relevant when monitoring media streaming endpoints. A 206 on a streaming endpoint is healthy behavior, not a failure.
Monitoring tip: A 200 response doesn't always mean healthy. Load balancers return 200 with error pages. CDNs return 200 with stale cached content. Configure your monitor to also validate a keyword in the response body (e.g., "status":"ok") to catch these cases.
3xx - Redirection
The client needs to take additional action to complete the request, usually by following a redirect.
| Code | Name | Meaning |
|---|---|---|
| 300 | Multiple Choices | The resource has multiple representations. The server provides options - the client chooses. Rarely used in practice. |
| 301 | Moved Permanently | The resource has a new permanent URL. Clients and crawlers should update their references. Cached by browsers and proxies. |
| 302 | Found | Temporary redirect. The resource is temporarily at a different URL. Clients should continue to use the original URL for future requests. |
| 303 | See Other | Redirect to a different URL, and use GET to retrieve it. Used after POST/PUT to redirect to a confirmation page (Post/Redirect/Get pattern). |
| 304 | Not Modified | The resource hasn't changed since the client's cached version. No body is returned - the client uses its cache. Requires If-Modified-Since or If-None-Match in the request. |
| 307 | Temporary Redirect | Redirect, but the method and body must be preserved. Unlike 302, a POST stays a POST after the redirect. |
| 308 | Permanent Redirect | Like 301, but the method and body must be preserved. A POST to a 308 URL stays a POST at the new URL. |
3xx codes you'll encounter most
301 Moved Permanently - HTTP → HTTPS redirects, domain migrations, URL restructuring. Your monitoring tool should follow redirects by default. If it doesn't, a site that redirects HTTP to HTTPS will always trigger an alert.
302 Found - Temporary redirects. Common in login flows, A/B testing, and temporary maintenance pages.
304 Not Modified - Normal caching behavior. If your uptime monitor sends conditional requests and gets 304, it's a valid healthy response - configure your monitor to accept it.
307 vs. 302 - If you're running a redirect after a POST (e.g., redirect after form submission), 307 preserves the POST method while 302 doesn't guarantee it. Modern clients treat 302 as a GET redirect in practice.
Monitoring tip: If your monitor detects a redirect chain longer than 3-4 hops, that's a misconfiguration worth investigating. Excessive redirect chains add latency and can cause loops.
4xx - Client Errors
The server received the request but couldn't process it because of a problem with the request itself. The client - browser, API consumer, or monitoring probe - sent something invalid.
| Code | Name | Meaning |
|---|---|---|
| 400 | Bad Request | The server can't process the request due to malformed syntax, invalid parameters, or deceptive routing. |
| 401 | Unauthorized | Authentication required. The client hasn't provided credentials or provided invalid ones. The WWW-Authenticate header tells the client what authentication scheme to use. |
| 402 | Payment Required | Reserved for future use, originally intended for digital payments. Some APIs use it for rate-limiting behind paywalls. |
| 403 | Forbidden | The server understands the request but refuses to authorize it. The client is authenticated but lacks permission. Unlike 401, re-authenticating won't help. |
| 404 | Not Found | The resource doesn't exist at this URL. May be permanent or temporary. The server isn't saying whether it ever existed. |
| 405 | Method Not Allowed | The HTTP method used isn't supported for this resource. A GET request to an endpoint that only accepts POST. The response includes an Allow header listing valid methods. |
| 406 | Not Acceptable | The server can't produce a response matching the client's Accept headers. The server can't provide the content type the client requested. |
| 407 | Proxy Authentication Required | Like 401, but the proxy (not the origin server) requires authentication. |
| 408 | Request Timeout | The client took too long to send the full request. The server closed the connection. |
| 409 | Conflict | The request conflicts with the current state of the resource. Common in concurrent update scenarios - two clients trying to modify the same resource simultaneously. |
| 410 | Gone | The resource existed but was permanently removed. Unlike 404, the server explicitly confirms it's gone forever. |
| 411 | Length Required | The server requires a Content-Length header but the request didn't include one. |
| 412 | Precondition Failed | Conditional request headers (If-Match, If-Unmodified-Since) didn't match the resource's current state. |
| 413 | Content Too Large | The request body exceeds the server's allowed size. Common when uploading files that exceed configured limits. |
| 414 | URI Too Long | The request URI is longer than the server will process. Usually caused by extremely long query strings. |
| 415 | Unsupported Media Type | The server won't accept the request because the Content-Type doesn't match what it expects. Sending XML to an endpoint that only accepts JSON. |
| 416 | Range Not Satisfiable | The range in a range request (Range: bytes=500-999) doesn't overlap with the actual resource. |
| 417 | Expectation Failed | The server can't meet the requirements specified in the Expect request header. |
| 418 | I'm a Teapot | An April Fools' joke from RFC 2324 (1998). A teapot refuses to brew coffee. Some APIs use it as a custom error code. |
| 421 | Misdirected Request | The request was directed at a server that can't produce a response. Common in misconfigured TLS/SNI setups. |
| 422 | Unprocessable Content | The request is well-formed but contains semantic errors. Common in REST APIs: the JSON is valid, but the values are logically invalid. |
| 423 | Locked | The resource is locked. (WebDAV) |
| 424 | Failed Dependency | A previous request in a batch failed, causing this one to fail. (WebDAV) |
| 425 | Too Early | The server won't process the request because it might be a replay attack. (TLS 1.3 early data) |
| 426 | Upgrade Required | The client must switch to a different protocol (specified in Upgrade header) to use this endpoint. |
| 428 | Precondition Required | The server requires conditional request headers (If-Match) to prevent lost updates - but the client didn't send them. |
| 429 | Too Many Requests | The client has sent too many requests in a given time window. The response usually includes Retry-After. |
| 431 | Request Header Fields Too Large | The request headers are too large for the server to process. |
| 451 | Unavailable For Legal Reasons | The resource is unavailable due to legal demands - copyright, court orders, government censorship. Named after Fahrenheit 451. |
4xx codes you'll encounter most in monitoring
400 Bad Request - If your monitor hits a 400, check the request configuration. The endpoint changed its expected parameters and your monitor's request is now malformed.
401 Unauthorized - Your monitor is hitting an authenticated endpoint without credentials, or credentials expired. Update the monitor's authentication configuration.
403 Forbidden - The server actively refuses the request. Common causes: IP allowlist that doesn't include your monitoring probe IPs, rate limiting, or a security policy change. Check if your monitoring provider's IP ranges are allowlisted.
404 Not Found - The monitored URL was deleted, renamed, or never existed. Verify the URL is correct. Don't monitor staging endpoints that get deleted between deployments.
429 Too Many Requests - Your monitoring probe is hitting a rate limit. Increase check intervals or whitelist monitoring IPs from rate limiting.
Monitoring tip: 4xx responses from uptime monitors usually indicate a misconfigured monitor, not a real outage. If you're getting 401 or 403 alerts from a production endpoint that was working, check whether authentication credentials rotated or IP allowlists changed.
5xx - Server Errors
The server received a valid request and failed to fulfill it. These represent genuine server-side problems.
| Code | Name | Meaning |
|---|---|---|
| 500 | Internal Server Error | A generic server-side failure. The server encountered an unexpected condition. Check server logs immediately. |
| 501 | Not Implemented | The server doesn't support the functionality required to fulfill the request. The request method isn't supported at all (unlike 405, which is per-resource). |
| 502 | Bad Gateway | The server is acting as a gateway or proxy and received an invalid response from the upstream server. |
| 503 | Service Unavailable | The server is temporarily unable to handle the request - due to overload, maintenance, or a crashed upstream. Often includes a Retry-After header. |
| 504 | Gateway Timeout | The server (acting as a gateway) timed out waiting for a response from an upstream server. |
| 505 | HTTP Version Not Supported | The server doesn't support the HTTP version used in the request. |
| 506 | Variant Also Negotiates | Server configuration error in content negotiation. |
| 507 | Insufficient Storage | The server can't store the representation needed to complete the request. (WebDAV, also used by some APIs) |
| 508 | Loop Detected | The server detected an infinite loop while processing. (WebDAV) |
| 510 | Not Extended | The server requires further extensions to fulfill the request. |
| 511 | Network Authentication Required | The client must authenticate to gain network access. Used by captive portals (hotel Wi-Fi, etc.). |
5xx codes you'll encounter most in monitoring
500 Internal Server Error - The catch-all server failure. Your application threw an unhandled exception, crashed, or hit a bug. Check application logs immediately.
502 Bad Gateway - Your web server (nginx/Apache) can't reach your application server (Node, Python, Ruby, etc.). The upstream process crashed, isn't running, or isn't accepting connections. Check if your app server process is running.
503 Service Unavailable - The service is intentionally or unintentionally offline. During planned maintenance, return 503 with a Retry-After header. During unplanned outages, 503 usually means your app is down or overwhelmed.
504 Gateway Timeout - A slow database query, external API call, or background process is blocking your web server from responding within the timeout window. The upstream is alive but too slow.
502 vs. 503 vs. 504: the practical difference
| Code | What it means | First thing to check |
|---|---|---|
| 502 | Upstream is down or returning errors | Is the app server process running? |
| 503 | Service is unavailable | Is the service overloaded? Is maintenance active? |
| 504 | Upstream is alive but too slow | Are there slow database queries? External API timeouts? |
Monitoring tip: Configure your monitoring tool to alert immediately on any 5xx from production endpoints. A single 500 from a health check endpoint that normally returns 200 is worth investigating. 5xx on a health endpoint almost always indicates a real problem.
Quick Reference: Codes by Situation
During deployment
| Code | Likely cause |
|---|---|
| 502 | App server not yet started after deploy |
| 503 | Zero-downtime deployment in progress |
| 500 | Code bug introduced in the new release |
Auth-related
| Code | Likely cause |
|---|---|
| 401 | Missing or expired credentials |
| 403 | Valid credentials, insufficient permissions |
| 407 | Proxy authentication required |
Rate limiting
| Code | Likely cause |
|---|---|
| 429 | Client sent too many requests |
| 503 | Server-side throttling (not per-client) |
API errors
| Code | Likely cause |
|---|---|
| 400 | Malformed request body or invalid parameters |
| 409 | Concurrent edit conflict |
| 422 | Valid syntax, invalid business logic |
Redirects to know
| Code | Behavior |
|---|---|
| 301 | Permanent, GET after redirect |
| 308 | Permanent, preserves method |
| 302 | Temporary, GET after redirect (in practice) |
| 307 | Temporary, preserves method |
What to Monitor Against
For uptime monitoring, the most useful configuration:
- Alert on: Any 5xx response from production endpoints
- Alert on: 4xx responses that change from baseline (a 200 suddenly returning 404 or 403)
- Don't alert on: 301/302 if your monitor follows redirects and the final destination returns 200
- Don't alert on: 304 if your monitor sends conditional requests
- Validate body content: Don't rely on status code alone - a 200 with an error page in the body is a failure
The most dangerous monitoring gap isn't alerting on 500 - it's a service returning 200 with an upstream error page because the load balancer is still responding while the app is down.
Top comments (0)