Errors and logs

"The save button doesn't work."

That sentence contains no information. Claude Code will still answer it, confidently, because it always answers. It will guess at a cause, change a file, and hand you back something that compiles. Sometimes the guess is right. When it is wrong you now have two problems, and the second one is yours.

The idea

Software fails in layers, and each layer keeps its own record. The browser knows the request came back with an error. The server knows which line of your code threw. The database knows the rule that was actually violated. Only the deepest layer holds the cause, and only the top layer is the one your user sees. The whole skill is walking down that stack, in order, copying the exact words at each level, until you reach a message that explains rather than reports.

  you click Save
        |
        v
  [ browser ]    devtools > Console:  POST /api/orders 500
        |                              (a symptom, not a cause)
        v
  [ server  ]    journalctl -u myapp:  TypeError at orders.ts:41
        |                              (where it stopped)
        v
  [ database ]   null value in column "email" violates not-null constraint
                                       (the cause)

How it works

Three places hold the record, and you should know how to open all three.

• The browser console. Press F12 in Chrome, Firefox or Safari and pick the Console tab. Red lines are errors your page hit while running. The Network tab next to it shows every request the page made and what came back. A red 500 there means your server failed, so stop looking at the frontend.
• The terminal. While npm run dev is running, the terminal window it is running in is your server log. It scrolls past fast. Scroll back.
• The server logs in production. On a Linux box running your app under systemd, that is journalctl -u myapp -n 200. On Vercel, Railway or Fly.io it is a Logs tab in the dashboard. Find yours now, while nothing is broken.

A stack trace reads top down. The first line is the error type and message. The lines under it are the trail of calls that got there, most recent first. Skip past everything inside node_modules. The first line naming a file you wrote is where you start, because that is the first place you have any control.

What to do

1. Copy the exact message. Not your paraphrase of it. The literal string, including the file name and line number, because the search value is in the exact wording.
2. Write down the smallest sequence that makes it happen again: what you clicked, what you typed, what you expected, what appeared. If you cannot make it happen twice, you cannot tell whether a fix worked.
3. Give the AI all of it at once. Paste the trace, the reproduction steps, and the relevant file. Then ask what the trace implies before asking for a fix. "Which line failed, and what was null?" gets a better session than "fix this".

Where it breaks

Logs go missing. Many hosts keep only a rolling window, so a failure from last Tuesday may be gone before you look. Logs also contain things you must not paste into a chat window: email addresses, session tokens, database URLs. Read what you are pasting.

And some failures do not reproduce. Anything that depends on timing, on two requests arriving at once, or on one specific user's data will look fixed the moment you retry it. Cannot reproduce is not the same as fixed. Leave it open.