HTTP Status Codes: Complete Reference Guide (2026)

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

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.