Skip to content

HTTP Status Code Lookup

Pure frontend: type a status number or a keyword (like 502 or timeout or rate) in the box and the table narrows to matches. Nothing leaves your browser — no network call, nothing recorded.

How to use

Type a status code or a keyword into the filter; the table shows only matching rows. Try 429 for rate limiting, or gateway for every gateway-related code.

Classes at a glance

First digit Class Meaning Owner
1 Informational request received, continue protocol
2 Success request handled fine server
3 Redirection further action needed both sides
4 Client error the request itself is wrong client
5 Server error server failed to handle server

One-line split: 4xx looks at the request, 5xx looks at the service. See a 5xx and think "is my service or upstream down"; see a 4xx and think "did the caller send something wrong".

Common status codes

Code Meaning Ops scenario
100 Continue client may keep sending the body (probe before large uploads)
101 Switching Protocols protocol upgrade, common in WebSocket handshake
200 OK success, the most normal health signal
201 Created resource created, common on REST write endpoints
204 No Content success with no body, used for deletes or heartbeats
206 Partial Content range request hit, used by download tools
301 Moved Permanently permanent redirect, transfers SEO weight, prefer for domain change
302 Found temporary redirect, no weight transfer, campaign pages
304 Not Modified cache hit on conditional request, not an error
307 Temporary Redirect temporary, method preserved
308 Permanent Redirect permanent, method preserved
400 Bad Request malformed request, gateways often reject for this
401 Unauthorized not authenticated, missing or expired token
403 Forbidden authenticated but not allowed, distinct from 401
404 Not Found resource missing, route mismatch or wrong path
405 Method Not Allowed wrong verb (e.g. GET against a POST endpoint)
408 Request Timeout client too slow, server gave up waiting
409 Conflict resource conflict, common on concurrent writes
413 Payload Too Large body exceeds limit, check upload size config
416 Range Not Satisfiable invalid range, resume download broke
429 Too Many Requests rate limited, back off or raise quota
500 Internal Server Error uncaught server exception, check app logs
502 Bad Gateway upstream returned invalid response, check if upstream crashed
503 Service Unavailable overloaded or under maintenance, often with Retry-After
504 Gateway Timeout gateway waited for upstream and timed out
507 Insufficient Storage server storage full, check disk or quota
508 Loop Detected proxy forwarding loop

Triage patterns for the high-frequency codes

The 502 / 503 / 504 trio: all three happen at the link between a gateway (Nginx, LB, CDN) and upstream. 502 means upstream returned an invalid response (the process may have just crashed); 503 means upstream explicitly says "I'm not taking it" (overload protection or maintenance page); 504 means upstream was too slow and the gateway timed out. Debug order: is the upstream process alive → how is upstream latency → finally the gateway's proxy_read_timeout / proxy_pass config. The three often appear together because the root cause is one upstream failure.

429 rate limiting: being rate limited is not you being wrong, just too fast. Clients must back off per Retry-After; servers must confirm the limit is sane and not misconfigured as a shared global bucket. Both Nginx limit_req and API gateways can return 429.

401 vs 403: 401 is "who are you" (no credential or expired token); 403 is "I know who you are but you may not enter" (role or permission). When an API call is blocked, first see whether the token is missing (401) or the role is wrong (403) — completely different directions.

304 is not an error: many panic at any non-200, but 304 means caching works. The client asks "did it change?" with If-Modified-Since or ETag; the server says "no" and returns 304, the browser reuses its cache. It saves substantial bandwidth and is a good thing.

Status codes from the monitoring view

Status codes are the first signal of health checks. Probes like blackbox-exporter fetch the code a target returns: expect 200, get 502, the probe alerts immediately. The three panels to watch are 2xx ratio, 4xx trend, 5xx spike — a 5xx jump basically means something broke, and a 4xx spike usually means a bad client release or a changed API contract. Treat status codes as metrics and you learn earlier than any user complaint.

Which codes are safe to retry

Seeing non-2xx does not always mean retry, and blind retries amplify outages. The rule of thumb:

  • Retryable: 408, 425 (Too Early), 429 (back off per Retry-After), 500, 502, 503, 504 (upstream jitter; short backed-off retries usually recover).
  • Do not retry blindly: among 4xx, except 408/425, the rest are wrong requests — retrying yields the same result and just floods error logs. 429 must back off; hammering it gets you blocked longer.
  • Idempotency first: retry only safely idempotent writes (GET is naturally idempotent; a non-idempotent POST like placing an order could double-charge, so rely on client dedup or a server-side idempotency key).

Picking the right code in a REST API

When writing endpoints, do not wrap every error in a 200. Use correct semantics:

  • Create succeeds with 201, delete with 204, "resource not found" with 404 (not a 200 with an empty array).
  • Input validation failure is 400, not 500 — classifying user error as a server exception misleads triage.
  • An auth-required endpoint without a credential returns 401; with a credential but wrong role returns 403; keep them distinct.
  • Resource conflict (e.g. concurrent edit of the same row) returns 409, letting the client decide how to merge.

Use codes correctly and callers can route handling properly; monitoring can also split "client problem" from "server problem" by first digit.

Status-code quirks at the edge / CDN

CDNs and edge nodes wrap a layer in front of your origin, and sometimes the code is not from the origin:

  • An edge cache hit may return 200 (or 304) without ever hitting origin, so the request never appears in origin logs.
  • Edge-to-origin timeout makes the edge return 502 / 504, but the root cause is origin or the link, not the edge itself.
  • A WAF rule on the edge returns 403, often with a custom error page that looks different from an origin 403.

When triaging 5xx, first tell "who returned this code": response headers like Server / X-Cache / Via quickly place it at the edge or the origin.

A real triage story

One day the 5xx alert spiked; the panel showed mostly 502. Following the playbook: is the upstream process alive? Yes. Latency high? No. It turned out a config change had dropped the gateway's proxy_read_timeout from 60s to 3s, while a slow endpoint's p99 sat at 4s — so normal requests were judged timed out by the gateway and got 502, even though the origin finished at 4s. Restoring a sane timeout and caching the slow endpoint made 502 vanish instantly. A 502 is not necessarily an upstream crash; it can be "the gateway lost patience" — remember that and you save a lot of wasted time.