HTTP Status Codes Reference

Getting to the Right Code Faster

• Search by keyword, not just number, when you don't remember the code. Typing "timeout" or "rate limit" surfaces every matching code instead of guessing at a number.
• Turn on non-standard codes before assuming a 5xx response is invalid. Codes like 522 or 524 look unfamiliar but are real, documented Cloudflare responses, not application bugs.
• Use Compare Mode the moment two codes feel interchangeable. 401 vs 403 and 502 vs 503 vs 504 are the two mix-ups that cause the most wasted debugging time.
• Check the Common Causes list before writing custom error-handling logic. It's often faster to recognize which listed cause applies than to trace the bug from scratch.

Features

Five Classes, and What Each One Actually Signals

Every HTTP status code's first digit tells you its class before you even read the rest of the number, and that first digit alone answers the most important question: whose problem is this? 1xx codes are informational — the exchange is still in progress. 2xx means success, plain and simple. 3xx means the client needs to look somewhere else to get what it wants. 4xx puts the problem squarely on the request itself — something the client sent was wrong, missing, or not permitted. 5xx means the request was probably fine, but the server broke while handling it.

That single-digit triage is genuinely useful under pressure. Seeing a wave of 4xx errors in a monitoring dashboard points toward a client-side integration problem, a broken frontend release, or bots hitting endpoints with malformed requests. A wave of 5xx errors points inward — toward the server, the database, or infrastructure — regardless of what any individual client sent. Reading the class first, before drilling into the specific three-digit code, is the fastest way to know which team should even be looking at the problem.

The numbering itself isn't arbitrary either. Status codes were deliberately grouped into blocks of roughly a hundred per class specifically so a new, more specific code could be added later without breaking the pattern — which is exactly what happened repeatedly over the decades since HTTP/1.0, from 429 Too Many Requests arriving in 2012 to formalize rate limiting, to 451 Unavailable For Legal Reasons arriving in 2018 for legally mandated takedowns. The registry has genuinely grown to reflect real problems the web ran into, not stayed frozen at whatever a 1990s specification originally anticipated.

The Codes Everyone Eventually Confuses

A handful of status code pairs get mixed up constantly, and almost always for the same reason — they describe genuinely similar situations from slightly different angles. 401 and 403 are the classic case: 401 means the server doesn't know who's asking, while 403 means it knows exactly who's asking and has decided no. The fix for one is better credentials; the fix for the other is a permissions change, and applying the wrong fix wastes real debugging time.

The redirect family causes similar confusion for a historical reason rather than a conceptual one. 302 never specified clearly whether a POST should stay a POST after redirecting, so browsers ended up disagreeing, and 303 and 307 were introduced specifically to remove that ambiguity — 303 forces a GET on the new URL, 307 guarantees the original method is preserved. 308 does the same job as 307 but for a permanent move instead of a temporary one.

502, 503, and 504 all sound like "something's broken upstream," but they mark three distinct points of failure a proxy can observe: 502 means the upstream answered with garbage, 503 means the upstream is deliberately not accepting requests right now, and 504 means the upstream never answered at all before the proxy gave up waiting. Distinguishing between them narrows a 5xx incident down considerably before anyone even opens a log file.

400 and 422 cause a quieter but equally common mix-up, particularly in API design discussions. 400 Bad Request is meant for requests the server can't even properly parse or understand — broken JSON, a missing required field, a value of the wrong type entirely. 422 Unprocessable Content is for requests that parse perfectly fine and are handed off correctly, but fail once the server actually evaluates them against a business rule — an email address that's syntactically valid but already registered to another account, for example. Using 400 for both cases isn't technically wrong, but it throws away a genuinely useful distinction between "you sent me garbage" and "you sent me something valid that I still can't accept."

Where the Non-Standard Codes Come From, and Why They're Worth Knowing

The official HTTP registry has exactly one code — 502 — for "the proxy got a bad response from upstream," which is far too coarse for anyone actually operating infrastructure at scale. Cloudflare's 520 through 530 series exists to fill that gap with genuinely useful specificity: 521 means the origin refused the connection outright, 522 means the TCP handshake itself timed out, 523 means Cloudflare couldn't even resolve a path to the origin, and 525 means an SSL handshake failed partway through. None of that detail exists in the standard registry, but all of it is real and documented, which is exactly why treating an unfamiliar 5xx-series number as automatically wrong is a mistake worth avoiding.

nginx contributes a different flavor of non-standard code, mostly for internal logging rather than anything sent to real clients — 444 (connection closed with no response) and 499 (client disconnected before the response finished) show up constantly in nginx access logs but describe situations a client never actually sees on their end. Framework-specific codes round out the picture: Laravel's 419 for an expired CSRF token, or the older Twitter-era 420 for rate limiting before the platform adopted the standard 429. Recognizing where a code actually comes from — official registry, a specific CDN, a specific web server, or a specific framework — is often the fastest route to the right fix, and worth confirming against the actual response body with the HTTP Header Checker before assuming which layer of the stack produced it.

This matters more than it might seem for anyone setting up alerting or on-call monitoring. Treating every unfamiliar 5xx code as an unhandled application exception generates noisy, misleading pages — a burst of 522s is almost certainly a Cloudflare-to-origin connectivity issue, not a bug in application code, and routing it to the wrong team wastes exactly the kind of time an incident response process is supposed to save. Building a monitoring dashboard that recognizes vendor-specific codes for what they actually are, rather than lumping every non-200 response into one generic "error rate" metric, produces alerts that point at the right system from the very first notification instead of after a round of manual investigation.

The same awareness helps outside of production incidents too. A QA engineer testing an integration against a third-party API benefits from knowing that a 429 response almost certainly means the test suite needs backoff logic, not a bug report, while a developer debugging a broken staging deployment behind Cloudflare benefits from recognizing 521 as "check whether the origin server process is actually running" rather than digging through application logs that were never going to show the problem in the first place.

Frequently Asked Questions