What HTTP 403, 404, 429, 500, 502, and 503 errors actually mean

HTTP status codes are tiny three-digit verdicts the server returns about your request. Most of the time you can ignore them — the browser collapses every 200 OK into "the page loaded." When something is broken, the code is the most important piece of information you have. The same blank page can be caused by half a dozen completely different problems, and the status code is the one place the server tells you which.

This is the field guide for the six codes you'll actually see: 403, 404, 429, 500, 502, and 503. Each one says something specific. Telling them apart cuts the time you spend debugging by more than half.

The five-class framework

Before the specific codes, the class shortcut. The first digit tells you everything you need to triage:

• 1xx — Informational. You'll basically never see one. Used for protocol-level negotiation (100 Continue, 101 Switching Protocols). Move on.
• 2xx — Success. The request worked. 200 OK is the boring happy path; 201 Created and 204 No Content show up on APIs.
• 3xx — Redirection. The server is sending you somewhere else. 301 is permanent, 302 is temporary. Browsers follow both silently. The redirect chain matters as much as the final status when something breaks mid-chain.
• 4xx — You did something wrong. Bad URL, missing auth, expired session, asking for something that isn't there, asking too often.
• 5xx — They did something wrong. The request reached the server, but the server failed to produce a usable response.

That's the whole framework. 4xx is on you, 5xx is on them. Everything else is the question of which specific 4xx or 5xx.

403 Forbidden

The server understood your request. It is refusing to serve it. The resource exists; you cannot have it.

What it usually means

1. Authentication is missing or wrong. You hit a page that requires a login and your session expired or the cookie was lost. Re-authenticating usually fixes it.
2. Authorisation is wrong. You're logged in, but your account doesn't have permission for this specific resource. Common on internal admin paths, paid-tier features, and shared-document URLs you don't have access to.
3. The CDN's WAF is filtering you. Cloudflare, Akamai, Imperva, and similar services run rules that block traffic they think is a bot or an attacker. A VPN exit IP, an unusual user agent, a too-aggressive scraping pattern, or sometimes just being in a country the site has chosen to firewall will trigger a 403.
4. The origin is intentionally refusing automation. Many financial APIs and bank websites return 403 to anything that doesn't look like a real browser. This is not an outage — the site is choosing to be unfriendly to non-browsers. Our scoring logic explicitly ignores 401/403 responses for exactly this reason.

Diagnostic

Turn off your VPN and try again — that fixes the WAF case in seconds. If you're on a corporate network, check whether your company's proxy is injecting headers the destination doesn't like. If the 403 comes with a body containing a Cloudflare ray ID or an Akamai reference number, the WAF is the cause; if it just says "Forbidden" with no detail, it's more often an auth or permissions issue on the origin.

$ 

404 Not Found

The most famous status code in the world. The URL you asked for doesn't map to anything on the server. Either you typo'd the path, the page was removed, or you're following a cached link from somewhere stale.

What it usually means

1. The page genuinely doesn't exist. Old blog posts that have been deleted, products that have been discontinued, user accounts that have been removed.
2. The URL changed. Sites that rearrange their structure without proper redirects leak 404s for years afterwards. SEO blog archives, old documentation, marketing pages from previous brand cycles.
3. You're behind a path-based access control. Some apps return 404 instead of 403 to hide the existence of resources from people who shouldn't see them. GitHub does this for private repositories — a non-member sees 404, a member sees the repo.
4. A reverse proxy is misrouting. Less common but real: an nginx config that routes /api/* to the wrong upstream returns 404 from the wrong service.

Diagnostic

A 404 from the homepage of a major site is genuinely unusual — almost always a 404 is a sub-path issue. Check the URL letter-for-letter, then try the homepage of the same site. If the homepage loads, the site is fine and the specific path is the problem. If the homepage is also broken, you're looking at something else (almost certainly a 5xx in disguise, served as a 404 by the CDN's default error page).

The archive.org Wayback Machine is the fastest way to confirm whether a URL used to exist. If the page was indexed and isn't there now, you've found a deleted resource.

429 Too Many Requests

You're being rate-limited. The server is fine; you are sending too many requests. This is the only error code in the entire HTTP catalogue that's actively cooperating with you — the response includes a Retry-After header telling you when it's safe to try again.

What it usually means

1. You hit an API rate limit. Almost every public API has one. Limits are typically per-second, per-minute, or per-hour, and the response headers tell you which you tripped (X-RateLimit-Remaining, X-RateLimit-Reset).
2. A shared rate limit was tripped by someone else. If you're behind a shared IP (corporate NAT, mobile carrier-grade NAT, a popular VPN exit), someone else's bot activity can use up the rate budget for the whole IP. You see 429 even though you sent one request.
3. Aggressive anti-abuse on consumer sites. Login pages, password-reset flows, and search endpoints often have rate limits much tighter than the underlying API. Three failed login attempts can earn you a 429.
4. Your client is retrying too aggressively. Code that retries failed requests immediately on failure will hit 429 very quickly. Implementing exponential backoff is usually the fix.

Diagnostic

Read the Retry-After header — it's either an integer number of seconds or an HTTP-date. If the integer is small (1–60), wait it out. If it's large (3600+), you've been blocked at the policy level rather than the request-rate level and waiting alone won't help; the underlying behaviour needs to change first.

For an exhaustive walk-through of the five rate-limit algorithms behind 429 — token bucket, fixed window, sliding window log, sliding window counter, and leaky bucket — see what 429 Too Many Requests actually means.

500 Internal Server Error

The application caught an unexpected exception, or didn't catch one and the runtime did. Whatever was supposed to handle the request didn't. The status code says nothing useful beyond "the error came from inside the application."

What it usually means

1. Uncaught exception in application code. Null pointer, missing config, database connection failure that wasn't retried gracefully. The fix is in the application's server-side logs, not the response.
2. Misconfiguration. Application started, but a critical environment variable is wrong. Database URL pointing at a stale endpoint, secret rotated and not redeployed, feature flag set incorrectly.
3. Resource exhaustion that returns 500 instead of 503. Some frameworks return 500 when they run out of memory, because they can't get far enough into the request-handling pipeline to return the more-correct 503.
4. A bad migration or deploy. A common pattern: a deploy goes out, errors spike, status page goes red 10 minutes later. The error rate is the first signal; the status page is the second.

Diagnostic

As an end user, there's nothing you can do but retry. As a developer of the affected service, the response body sometimes contains a useful stack trace in development mode; production usually strips it. The X-Request-Id or similar response header (if present) lets you grep the server logs for that exact request.

Repeated 500s on a site you don't own almost always correlate with an active deployment or a downstream dependency going sideways. Give it 15 minutes; check the vendor's official status page; refresh.

502 Bad Gateway

A proxy — your CDN, nginx, an AWS Application Load Balancer, Cloudflare — made a request to the application's upstream server and got back something that wasn't a valid HTTP response. The proxy is reporting that it couldn't talk to the thing behind it.

What it usually means

1. The upstream is down or unreachable. Most common. Application server crashed; a container is in CrashLoopBackOff; the proxy can't open a TCP connection to the backend.
2. The upstream returned malformed HTTP. The application accepted the connection but wrote bytes the proxy couldn't parse. Less common; usually a bug in custom HTTP code or a protocol mismatch.
3. A connection reset mid-response. The application closed the socket before sending all the body it had promised in the headers.
4. SSL termination mismatch. The proxy is trying to talk HTTPS to an upstream that only speaks HTTP, or vice versa.

Diagnostic

If the site sits behind a CDN, the CDN's error page usually tells you which side broke. Cloudflare's 5xx series is particularly informative: a 521 means the origin server is refusing connections; a 522 means it's timing out; a 523 means DNS to the origin failed. See Cloudflare error codes decoded for the full breakdown.

For an end user, frequent 502s from a major site mean an active incident — wait 15 minutes and check the status page. For a developer, the proxy's error log (error.log on nginx, the CDN analytics dashboard on Cloudflare or AWS) names the exact failure mode.

503 Service Unavailable

The application is alive and conscious but is deliberately refusing the request. Either it's in maintenance mode, it's protecting itself from overload, or a circuit breaker upstream of it has tripped.

What it usually means

1. Maintenance mode. Operators turned the application "off" intentionally. There's often a Retry-After header indicating when it'll be back.
2. Rate limiting / overload protection. Application is up but refusing new requests to protect itself. Common during traffic spikes; preferable to a hard crash.
3. Health-check failure. Load balancer pulled the application out of rotation but didn't yet de-register it from the upstream pool. Some requests still briefly hit it.
4. Circuit breaker tripped. A dependency (database, cache, downstream service) is down; the application is refusing requests because it knows they'll fail.

Diagnostic

Check the Retry-After header — its presence and value tell you whether this is an intentional "back at X" or a bare 503 with no useful guidance. If the value is small, wait it out. If there's no header at all, you're looking at a less-disciplined 503 — back off manually, try again in 5–15 minutes.

503 during a scheduled deploy is normal. 503 outside a deploy window is more interesting — usually overload, sometimes a dependency outage. The five-state status-page vocabulary maps deploy-related 503s to maintenance and overload-related ones to major or critical; see what 'degraded performance' means on a status page.

For a full taxonomy of the 5xx codes — including 504, 520, and the Cloudflare-invented variants — see the 5xx family.

The quick-reference table

The whole field guide in one block:

If you're seeing a code that isn't on this list

The codes in this guide cover roughly 95% of real-world breakage. For the rest, use the full HTTP code reference at /http for plain-English explanations of every standard code, or paste the message into the Status Meaning Decoder for an instant translation. To confirm what code a specific site is actually returning — independent of your browser, network, or VPN — run it through the Website Down Checker; the result panel shows the exact HTTP status, the redirect chain, and the responding server.