The web's shortest conversations
Every time a browser meets a server, the exchange begins with a three-digit verdict. Before a single word of your page travels, the server announces how the conversation went: success, detour, your mistake, my mistake, or news too early to call. Those digits — HTTP status codes — are the most-read sentences on the internet, and among the least understood by the people who encounter them daily. StatusAtlas exists to translate them: every common code, in plain English, with the two things you actually need — when you will see it, and what to do next.
The codes organise into five families by their first digit, and learning the families is learning 80 percent of the system. 1xx is informational — hold on, processing. 2xx is success. 3xx is redirection — the thing you want lives elsewhere. 4xx blames the request: the client asked wrongly. 5xx blames the server: the request was fine and the kitchen is on fire. When a code you have never seen appears, its family alone tells you whose problem it is and where to start digging.
The success and redirect families
200 OK is the web's workhorse, but its siblings carry precision worth using: 201 when a POST genuinely created something, 204 when success is silent by design. Builders who return the right 2xx make APIs self-documenting; clients who check for the family rather than exactly 200 write integrations that survive upgrades. The 3xx family is about geography. 301 and 308 are permanent moves — update your records, search engines transfer their rankings — while 302 and 307 are temporary detours that preserve the original address's claim. Confusing the two is a classic, costly error: a 'temporary' redirect left in place for years leaks search value, and a permanent one issued during a weekend experiment can be cached by browsers with stubborn enthusiasm.
304 deserves a special nod: it is the sound of caching working. The browser asks 'has it changed?', the server answers 'no', and megabytes stay un-sent. Sites that feel magically fast on repeat visits are usually sites whose 304s are configured with intent.
4xx: the client-error family, decoded
The 4xx codes are where users and developers collide, because each one assigns the fault to the request — sometimes fairly, sometimes diplomatically. 400 means the request itself was malformed or incomplete. 401 means 'who are you?' — authentication missing or expired. 403 means 'I know who you are, and no' — a permissions problem that re-logging will never fix. 404, the celebrity of the family, means the address maps to nothing; 410 is its deliberate cousin, a tombstone for content removed on purpose, which search engines retire faster. 405 is a verb mismatch, 409 a state conflict, 422 a validation failure with the failing fields usually itemised in the response body — read it before changing anything.
Two 4xx codes deserve modern fluency. 429 — Too Many Requests — is the rate limiter's raised hand; the correct response is exponential backoff and respect for the Retry-After header, never an instant retry loop, which converts a pause into a ban. And 418, the teapot, began as an April Fools' joke and survives as a reminder that the people who built the web had humour — a few real APIs still wield it as a polite, unmistakable 'no'.
5xx: when the server is the story
Server errors share a user experience — 'it's not you, it's us' — but their fixes diverge sharply. 500 is a crash: somewhere, code met a case it could not handle, and the only cure lives in the server logs. 501 means the server never implemented what was asked. 502 and 504 are gateway dramas: the front door (a proxy or load balancer) is healthy, but the kitchen behind it returned nonsense (502) or took too long (504) — the signature pairing of deploys, crashed workers and database queries gone wandering. 503 is the honest overload or maintenance signal, and the one code where 'try again shortly' is literally the specification.
For site owners, the discipline is monitoring: log your 5xx rate, alert on its rise, and give users a status page instead of silence. For API consumers, the discipline is retry design: 5xx responses may be retried with backoff and jitter, 4xx generally may not — retrying a 403 a thousand times is a loop, not a strategy. The atlas entry for each code states its fix in one line because, mid-incident, one line is what anyone has time to read.
Using this atlas under pressure
Search by number when an error is on your screen; search by symptom-word — timeout, redirect, validation — when you are designing and want the right code before users meet the wrong one. Filter by family to study a class at once, the way you would before an interview or an API design review. The copy button on every entry drops a small fetch() snippet with that code's check pre-written, because handling statuses deliberately, per branch, is what separates an integration that degrades gracefully from one that fails theatrically.
Above all, treat status codes as a designed language, not weather. If you build anything on the web, you choose which codes your users and fellow developers will read at their worst moments. Choose precisely, document honestly, and the three digits will do more for your support load than a hundred FAQ pages.
A pocket history in three digits
Status codes arrived with HTTP in the early 1990s, borrowed in spirit from FTP's reply codes, and grew by accretion: the web's needs outran the original list, so new digits were standardised as new problems — rate limiting, legal takedowns, validation semantics — demanded names. Some codes are now near-extinct in the wild, others (looking at you, 404) became cultural artefacts printed on t-shirts. The system endures because it is small enough to memorise by family and expressive enough to run the world's largest machine. This atlas is your map to it — bookmark it for the day a strange number appears and everyone in the room turns to look at you.
Designing errors your users can act on
If you build APIs or sites, the atlas doubles as a style guide. Return the most specific code the situation earns — 422 for validation with a body naming the fields, 409 for conflicts the client can resolve, 410 for deliberate removals — and never let a framework's default 200-with-error-payload escape into the wild, because it poisons every client, monitor and cache downstream. Pair every error code with a human sentence and a machine-readable error key; the code tells the client what class of response to make, the sentence tells the human what to fix, and the key keeps analytics honest.
Equally, design the absence of errors: correct 304 caching, honest 503s during maintenance with a Retry-After, and redirects that respect permanence. Users forgive a well-explained detour; they do not forgive silence wearing a spinner. The three digits are tiny, but they are the part of your product that speaks when everything else has failed — make sure it speaks well.
The codes you will meet this week
Real-world frequency is brutally concentrated: a handful of codes — 200, 301, 304, 404, 500 — account for the overwhelming majority of all responses ever sent, and the atlas orders its teaching accordingly, depth where the traffic is. But the long tail is where professionalism shows: the developer who reaches for 429 with a Retry-After, or answers a validation failure with 422 and a field list, is writing fewer support tickets for their future self. Bookmark the atlas and skim one family per coffee break for a week; by Friday the whole map will feel like local geography, and strange numbers on screens will have stopped being weather and started being sentences you can read.
Frequently Asked Questions
What is the difference between 401 and 403?
401 means the server does not know who you are — log in or send a valid token. 403 means it knows exactly who you are and you are not allowed. Re-logging fixes 401; only a permissions change fixes 403.
Should I use 301 or 302 for a redirect?
301 (permanent) when the move is forever — browsers and search engines update their records and rankings transfer. 302 (temporary) for short detours like maintenance or tests, where the original URL keeps its claim.
What should my app do on a 429?
Slow down. Wait at least as long as the Retry-After header says, then retry with exponential backoff. Hammering a rate limiter converts a short pause into a longer block.
Is a 404 bad for SEO?
A few are normal — the web rots naturally. Many 404s on URLs that used to work waste crawl budget and disappoint visitors arriving from links. Redirect moved pages with a 301, and use 410 for content deliberately retired.
502 or 504 — which is which?
502 Bad Gateway: the proxy received an invalid response from the upstream server (often crashed or mid-deploy). 504 Gateway Timeout: the upstream simply took too long. Both are server-side; users can only retry later.
Why is 418 in the list — is it real?
It is genuinely standardised, born as an April Fools' RFC joke about teapots, and a few real services use it as a playful refusal. It is kept in the atlas because developers do meet it and deserve a straight answer with the smile included.