HTTP Status Codes Guide: 200, 300, 400, 500 Explained
Why This Guide Exists
When a site feels down, status codes are often the fastest way to understand what kind of failure you are dealing with. Most teams already know individual codes like 404 or 503, but in real incidents the most useful skill is understanding code families: 2xx, 3xx, 4xx, and 5xx.
This guide is the primary reference behind our Website Down Checker code links. It is written for both technical and non-technical readers, so you can quickly decide what to do next without overcomplicating the first response.
Quick Navigation
- Why This Guide Exists
- 200 vs 300 vs 400 vs 500 at a Glance
- How to Use Status Codes During an Outage
- 2xx: Success Codes
- 3xx: Redirect Codes
- 4xx: Client and Policy Codes
- 5xx: Server and Upstream Failure Codes
- How to Read Mixed Regional Signals
- Practical Triage Workflow
- HTTP Status Codes FAQ
200 vs 300 vs 400 vs 500 at a Glance
Use this as your mental model during the first 5 minutes of triage:
| Family | What It Usually Means | Typical User Impact | First Owner to Check |
|---|---|---|---|
| 2xx | Request technically succeeded | May still fail later in app flow | App team + frontend/API owners |
| 3xx | Redirect happened | Can be fine, or can create loops/misrouting | Edge, routing, SEO, app config |
| 4xx | Request rejected, invalid, unauthorized, or limited | Feature- or user-specific failure | Auth, WAF, rate-limit, API contract owners |
| 5xx | Server/upstream could not process successfully | Strong outage/degradation signal | Backend, infra, dependency owners |
How to Use Status Codes During an Outage
Status codes should help you route incidents, not end investigation too early. A single code from one endpoint is not enough to declare global health or global outage.
- Check distribution by endpoint, not only global totals.
- Check distribution by region, because edge behavior can differ by location.
- Check timeline, because shifts from 200 to 302 to 503 often show rollout or dependency failure progression.
- Tie status patterns to user journeys (login, search, checkout, API critical paths).
2xx: Success Codes (Not Always “Everything Is Fine”)
2xx means the server handled that request. It does not guarantee the full product experience works. For example, a homepage can return 200 while login API calls fail with 401/500 right after page load.
- 200 OK: Response succeeded. Best read with downstream checks.
- 204 No Content: Success with empty response body; often valid for APIs.
- 206 Partial Content: Range response, common in media/download flows.
Operational rule: treat 2xx as a good sign for reachability, then validate core flows before closing incidents.
3xx: Redirect Codes (Good, Until They Are Not)
3xx codes are normal when domains canonicalize (for example apex to www) or when URLs are moved. They become incident-relevant when they introduce loops, wrong protocol upgrades, or geo/session-specific redirects.
- 301 Moved Permanently: Long-term redirect; affects SEO and caching strongly.
- 302 Found: Temporary redirect; often used for auth flows and temporary routing.
- 307 Temporary Redirect and 308 Permanent Redirect: Method-preserving redirects, common in stricter API behavior.
If users report “site not loading” but checks show 3xx, inspect the redirect chain end-to-end. The issue is often at the destination URL or in a loop.
4xx: Client and Policy Codes (Often Misunderstood)
4xx is usually interpreted as a client-side mistake, but in production outages many 4xx patterns are policy or protection outcomes that still impact real users.
- 400 Bad Request: malformed input or incompatible client/request format.
- 401 Unauthorized: missing/invalid auth context.
- 403 Forbidden: request understood but blocked by policy.
- 404 Not Found: route missing, deploy mismatch, stale links, or service path moved.
- 408 Request Timeout: client/request timeout at the server boundary.
- 429 Too Many Requests: explicit rate limiting or abuse controls.
Operational rule: if 4xx rates spike suddenly without a release in client behavior, treat it as a potential platform/config incident, not just “user error.”
5xx: Server and Upstream Failure Codes
5xx is your strongest status-based outage signal. These codes usually indicate backend, gateway, or dependency failure and should trigger immediate owner routing.
- 500 Internal Server Error: application crashed, threw exception, or failed unexpectedly.
- 502 Bad Gateway: gateway received invalid response from upstream.
- 503 Service Unavailable: overloaded, maintenance mode, or temporary capacity protection.
- 504 Gateway Timeout: upstream did not respond in time.
In practice, mixed 500/502/503/504 in one incident can still come from one root cause. Follow the first failing hop in the request path.
How to Read Mixed Regional Signals
When one region returns 200 while another returns 502 or timeout, do not treat that as noise. Mixed results often indicate:
- CDN routing asymmetry
- regional dependency issues
- network policy filtering
- partial rollout problems
For non-technical teams, a useful external message is: “The service is reachable in some locations but unstable globally. We are validating regional paths now.”
Practical Triage Workflow (Fast and Repeatable)
- Collect the top 3 status codes by impacted endpoint.
- Compare those codes across at least two regions.
- Confirm whether core business journeys fail (not just synthetic homepage checks).
- Assign first owner by code family and request path.
- Publish a short incident note every 10-15 minutes with what changed.
Tip: If you are under pressure, avoid saying “everything is down” or “everything is fine” from one status code sample. Status families are direction, not a complete diagnosis.