4xx vs 5xx — Where to Look When an Error Appears

Why the guessing game starts

Anyone who has handed a web app to an AI knows the scene. Red text appears on screen, you screenshot it, the AI rewrites some code, it still fails, you screenshot again. A few rounds later, code has changed in several places and nobody knows what the original cause was.

The problem is not skill; it is information. If you do not know what is broken and you ask for a fix, the AI can only guess. Give it a single narrowed-down segment instead and the same AI usually fixes it in one shot.

Narrowing it down does not require programming ability. The browser is already showing half the answer, and there are only two rules for reading it: check the first digit, then walk the boundaries.

Where to find the status code

Every browser ships with developer tools. Press F12 on Windows or Command + Option + I on a Mac and a panel opens beside or below the page. Chrome, Edge, and Safari all have it, and there is nothing to install. Safari requires turning on the Develop menu once in settings.

You only need two of the tabs. Console collects messages left by frontend code (JavaScript). Network collects one line per request your page exchanged with the outside world. When something breaks, open Network first.

With the Network tab open, click the failing button again. A new line appears in the list. The culprit is the one marked in red, or the one whose Status column shows a 400- or 500-level number. Click it and you will see what you sent (Request) and what came back (Response).

What matters here is that number, not the error text on screen. Wording differs from service to service; the number is a worldwide convention.

One digit decides whose problem it is

A status code has three digits. The last two are the specific reason; the first is the broad category, and that alone tells you which side to look at.

The gap between 4 and 5 matters most in practice. A 4 means the sender is at fault, so check your page, your input, your URL. A 5 means the receiver is at fault, and no amount of editing your own code will help.

The codes you actually run into

There is no need to memorize the full list. About ten come up in real life, and all you need is what each one is telling you to check.

The difference between 401 and 403 is worth noting. A 401 says 'I do not know who you are', which is a login problem. A 403 says 'I know who you are, and you are not allowed', which is a permissions problem. In development the first is called authentication and the second authorization.

A 529 is not your fault

If you use Claude Code or the API, you will meet 529 often. It starts with a 5, so the situation is on the other server, not yours. Requests have piled up beyond what it can handle — people usually say the server is down.

Not knowing this leads to endlessly rewriting perfectly good code, which is the most common form of wasted effort here. When you see a code starting with 5, stop, wait a moment, and try again.

One caveat: a 500 coming from a backend you wrote is your server's problem. Separate a 500 your own service raised from a 5xx a third party raised. The Network tab settles it — just look at which address the request went to.

The five segments a request passes through

Once the first digit gives you a direction, narrow the location. That requires knowing what happens behind a single save. A web service is not one block; it is these five segments strung together.

1) Frontend. The screen the user sees. It sits at the very front from the user's point of view, hence the name. HTML holds the content, CSS styles it, JavaScript handles actions like clicks. Because it runs inside the browser, JavaScript is effectively the only language available here.

2) HTTP and APIs. The agreed format in which the screen and the server talk. You send a request to an address (URL) and get a response back, usually carrying data in JSON. That whole communication layer is what people call an API.

3) Backend. The invisible processing side. When a request arrives it checks who you are (authentication), whether you are allowed (authorization), whether the values are sane (validation), and then applies the actual rules.

4) Database. The memory of the service. It stores what the backend produced in table form and hands it back later.

5) Deployment and infrastructure. Where all of this actually runs. It is the step of leaving localhost, which only opens on your own machine, for somewhere other people can reach.

One term causes confusion. 'Server' does not only mean the backend program. From an infrastructure angle it also means the computer that program runs on. The backend is the program applying logic on top of that computer.

Failures happen between segments

In practice, trouble sits on the arrows between segments far more often than inside them. If something got slow, one arrow is delaying. If a save did not stick, one arrow broke.

So debugging becomes walking those arrows in order. Follow the four steps below and the culprit narrows to a single segment.

Step 1. Reproduce the broken action. With the Network tab open, click the button again.

Step 2. Check whether the request even left. If no new line appears, it was already blocked in the frontend — usually there is a JavaScript error waiting in the Console tab.

Step 3. If it left, read the status code. For a 4xx look at the values, address, and login state; for a 5xx look at the backend logs.

Step 4. If the backend looks fine, check whether the value actually landed in the database. A successful response with no stored data points at the save logic or the transaction.

Learn this order once and the next error starts with you already knowing the segment, before any screenshot is sent.

Ask the AI this question first

Most people paste the error and say 'fix it'. The AI then changes code to match the visible symptom. If the cause lives in another segment, that fix creates a new problem.

Ask about location first instead. The prompt below can be copied as is.

This question is not only for errors. Use the same frame when you meet an unfamiliar term and you will learn where that technology sits in the overall flow. Once you know the position, every other explanation has somewhere to attach.

Assume a user request flows frontend -> API -> backend -> database.
First decide which segment this error came from.
Tell me the status code and logs you based that on,
and if something still needs checking, tell me exactly what to capture for you.

Assume a user request flows frontend -> API -> backend -> database.
Explain which segment the technology just mentioned affects.
Also tell me which concepts I should understand before it.

When a term is new, look at the map

Even with the segments clear, new terms keep arriving. roadmap.sh is a good resource here. It draws role-based maps — frontend developer, backend developer — showing what to learn in what order, all in a single picture.

Using it is simple. Open the relevant roadmap and find where the thing blocking you sits. Items marked in purple are what the author recommends, which in practice means what is widely used. It is in English, but you can hand the picture to an AI and have it explained.

Done this way, terms stop piling up loose and start landing as coordinates on a map. That pays off later, both when searching and when asking an AI.

Bugs never reach zero

One expectation is worth resetting. No matter how experienced the developer, bug count never reaches zero. The same is true with an AI writing the code, and it may well produce more of them.

That is why most time in real development goes not into writing code the first time but into everything after: checking, shipping, hitting an error, fixing it again.

What you need in the end is not bug-free code but a fast way to locate a problem when one appears. Read the first digit, walk the boundaries, ask about location first. Those three end most of the guessing games.