The HTTP status codes that actually show up in day-to-day support and operations work, what each one really means, and which ones point at the client vs. the server.
Status codes are the fastest triage signal you get during an incident — before you open a single log file, the code itself already tells you roughly where to look: your application, a service it depends on, or the client making the request. Learning to read them correctly cuts investigation time significantly.
The status code families and what each range means, the specific codes that come up constantly in real support and operations work (as opposed to the dozens that exist but rarely matter), and how to tell from the code alone whether the fault is likely client-side, application-side, or upstream.
200 OK is the default; 201 Created and 204 No Content show up in APIs.301 Moved Permanently and 302 Found are the common ones; a redirect loop (the browser reports "too many redirects") is a real, recurring incident type.400 Bad Request — the request itself is malformed (bad JSON, missing required field). Almost always a client-side or integration bug, not a server outage.
401 Unauthorized — no valid authentication was provided. Distinct from 403 — 401 means "we don't know who you are," 403 means "we know who you are and you're not allowed."
403 Forbidden — the request is understood, but access is refused. Worth checking whether this is an actual permissions issue or a misconfigured security rule (a CSP or CORS policy, an IP allowlist, a WAF rule) blocking something legitimate.
404 Not Found — the resource doesn't exist at this URL. Common causes beyond "the page really doesn't exist": a typo'd route, a deployment that removed a page without a redirect, or a case-sensitivity mismatch on Linux-hosted static files.
429 Too Many Requests — rate limiting kicked in. If a legitimate client is hitting this, check whether a retry loop without backoff is hammering the endpoint.
500 Internal Server Error — a generic catch-all meaning the application crashed or threw an unhandled exception while processing an otherwise-valid request. The first place to look is the application's own error logs, not the network.
502 Bad Gateway — a server acting as a gateway or proxy (a load balancer, reverse proxy, or IIS in front of an app) got an invalid response from the upstream server it's forwarding to. This usually means the application process itself crashed or isn't running — the proxy is fine, but there's nothing valid behind it.
503 Service Unavailable — the server is temporarily unable to handle the request, often deliberately (overloaded, in maintenance mode, or a health check is failing and traffic is being intentionally withheld).
504 Gateway Timeout — like 502, but the upstream server didn't respond in time, rather than responding invalidly. This points at a slow dependency (a database query, an external API call) rather than a hard crash.
This distinction is worth internalizing specifically: 502 usually means "nothing is there to answer," while 504 usually means "something is there, but it's too slow." In an IIS + application-server setup, a 502 often points at the application pool being stopped or crashed (see IIS Application Pools), while a 504 more often points at a slow downstream call — a database under load, a third-party API having a bad day, or a connection pool exhausted. These point your first investigation step in genuinely different directions.
Status codes tell you what happened; the next layer is figuring out where in the chain it happened, covered in Isolating "Is It the Network or the App?". For the specific case of an IIS-hosted application returning 502s, see IIS Application Pools: What They Are and Why They Crash.
Part of: Freshers, Support Engineers, Sitecore Engineers