All posts
Networking4 min readWatchFor Team

HTTP Status Codes Explained: what 404, 500 and 503 really mean

Every status code is your server trying to tell you something. Here's a plain-English guide to the ones you'll actually meet — what they mean, whose fault they are, and what to do about each.

HTTP Status Codes Explained: what 404, 500 and 503 really mean

You push a deploy, refresh the page, and there it is in ugly grey letters: 502 Bad Gateway. Your stomach drops. Is it the server? The load balancer? The code? The internet itself?

Here's the good news: that number isn't random. Every HTTP status code is your server (or something between you and it) trying to tell you exactly what went wrong — if you know how to read it. Learn the handful that matter and you'll diagnose problems in seconds instead of panicking.

The five families

Every status code is a three-digit number, and the first digit tells you the category. Get this and you're already halfway there:

RangeFamilyRough meaning
1xxInformational"Hold on, still working." (You'll rarely see these.)
2xxSuccess"Here you go." Everything worked.
3xxRedirection"It moved — look over there instead."
4xxClient error"You sent something wrong."
5xxServer error"I messed up."

The single most useful distinction: 4xx is your fault, 5xx is the server's fault. A 404 means the browser asked for something that isn't there; a 500 means the server fell over trying to answer. That one rule points your debugging in the right direction immediately.

The codes you'll actually meet

You don't need all 70-odd codes. You need these.

Success and redirects

CodeNameWhat it means
200OKThe request worked. The happy path.
201CreatedYour POST created something (common in APIs).
204No ContentWorked, but there's nothing to send back.
301Moved PermanentlyThis URL has a new home — forever. Search engines update accordingly.
302Found (temporary redirect)Moved for now; keep using the old URL.
304Not Modified"Nothing changed, use your cached copy." A speed win.

Client errors (4xx)

CodeNameWhat it usually meansWhat to check
400Bad RequestMalformed request the server can't parseYour payload, syntax, params
401UnauthorizedYou're not logged in / no valid credentialsAuth token, login
403ForbiddenYou're known, but not allowedPermissions, IP allowlists
404Not FoundThat URL doesn't existThe path, typos, deleted pages
429Too Many RequestsYou're being rate-limitedSlow down, back off and retry

Server errors (5xx)

CodeNameWhat it usually meansLikely culprit
500Internal Server ErrorThe app crashed handling the requestA bug, an unhandled exception
502Bad GatewayA proxy got a junk response from upstreamApp down behind the load balancer
503Service UnavailableServer is up but can't serve right nowOverload, or maintenance mode
504Gateway TimeoutUpstream took too long to respondA slow app, DB or dependency

The 5xx trio that causes the most panic

500, 502, 503 and 504 look similar but tell very different stories:

  • 500 — your application itself threw an error. Check your logs; there's almost always a stack trace.
  • 502 — something in front of your app (a proxy, load balancer, CDN) tried to reach it and got nothing usable. Usually your app crashed or isn't listening.
  • 503 — the server is alive and answering, but deliberately saying "not now" — often overload or a maintenance page.
  • 504 — the front layer waited for your app and gave up. Your app (or a database/third-party it calls) is too slow.

A quick mental shortcut: 502 = "the thing behind me is dead", 504 = "the thing behind me is slow". That distinction alone saves a lot of wrong turns.

Why this matters for monitoring

Status codes are the backbone of uptime monitoring. When a monitor checks your site, the code is the first thing it reads:

  • A 2xx is treated as healthy.
  • A 4xx or 5xx can be treated as down — though a good setup lets you decide (a 401 on a protected endpoint might be expected).
  • Sudden 5xx spikes are the classic signal of a real outage.

But there's a trap: a page can return 200 OK and still be broken — a blank page, an error rendered in the body, the wrong content entirely. That's why solid monitoring pairs the status code with a keyword (body) check, so "200 but broken" still counts as down.

The bottom line

If you remember one thing……make it this
First digittells you the family: 2 good, 3 moved, 4 your fault, 5 server's fault.
4xx vs 5xxpoints your debugging in the right direction instantly.
502 vs 504"dead upstream" vs "slow upstream".
200 isn't enoughpair status checks with a content check to catch "200 but broken".

Status codes feel cryptic until they don't. Once these click, that grey 502 stops being a mystery and starts being a map.

Want something watching your status codes around the clock? Our HTTP monitoring guide shows how to alert on the right ones — and you can inspect any URL's response right now with the free HTTP header checker.

Share this article