Classifying the failure before you fix it

Where, before what

A broken app gives you a symptom. The useful first move is not to guess a cause but to place the failure in one of five zones, because each zone has one place to look and you can reach the right one in under a minute.

The blank white page

Nothing rendered. Almost always a JavaScript error during the first render.

Open the console. There will be a red line, and it is usually the only one that matters: everything below it is a consequence. The most common cause by far is reading a property of something that has not arrived yet, which means the component assumed data it did not check for.

A blank page with a clean console is different: the request may have returned an empty list and the component has no empty state. Check the network panel before assuming a crash.

The 500 page

Your server code threw. The user sees nothing useful on purpose.

Look in the terminal running the dev server, or your host’s logs in production. The stack trace is there in full. If your logs show nothing at all at that moment, the request may never have reached your code: check the URL and the status code in the network panel, because a 404 dressed up as a generic error page looks identical to the user.

The 404

No route matched. Three usual causes, in order of frequency: a typo in the path, a file in the wrong folder so the framework never registered it, and a case mismatch that works locally and fails on the Linux server.

If the page exists but a fetch inside it 404s, read the exact path in the network panel. A leading slash missing turns /api/bookings into a relative path that resolves somewhere else entirely.

The 401 and the 403

These are different and the difference is the diagnosis. 401 means the server does not know who you are: the session is missing or expired, or a cookie is not being sent. 403 means it knows and is refusing: you are logged in as the wrong person, or a permission check is stricter than intended.

Generated code frequently returns one where it means the other, which sends you looking in the wrong half of the system. Worth checking that the code returning it is honest.

The silent wrong answer

No error anywhere. A number is wrong, a list is missing three rows, a total does not add up. This is the dangerous category, because nothing announces it and it can sit in production for months.

There is no log to read. The move is to ask the database the same question directly and compare with the screen. Whichever side disagrees with your expectation is the side to investigate, and that single comparison usually cuts the problem in half.

It works here and not there

Same code, different behaviour on your laptop and in production. The zone is configuration, not logic, and the shortlist is short: a missing environment variable, a database that has not had its migrations run, filename capitalisation, a Node version difference, or a build step that behaves differently from the dev server.

A whole lesson later in this block is about this one, because it accounts for a large share of first deployments.

Ask the classifying question first

Before you paste anything anywhere:

Did this happen in the browser, on the server, in the database, or in the network between them?

Thirty seconds with the console and the network panel answers it, and the answer determines everything after. A great many long, frustrating debugging sessions are somebody looking in the browser for a problem that happened on the server.

Write the classification into the request

Server-side 500 on POST /api/bookings, every time, since I added
the overlap check. Terminal shows:
[first three lines]
Browser console is clean. The request body looks correct in the
network panel. Nothing changed in the database.

That is a diagnosis handed over, not a symptom. It tells the model where not to look, which is worth as much as telling it where to look, and it prevents the response that begins by rewriting your React component for a problem that never touched the browser.