How to Read an Error Message (and Fix Things Faster)
Error messages look like walls of gibberish, but they usually tell you exactly what went wrong and where. How to find the one line that matters, what common errors actually mean, where to look when there's no error at all, and what to give an AI so it can fix it first time.
Something breaks, and the screen fills with red text: file paths, strange words, numbers, forty lines of it. The natural reaction is to panic, or to copy the whole thing to an AI and hope.
But error messages aren't random. They're the computer telling you precisely what went wrong — and learning to read them, even roughly, makes you dramatically faster at fixing things, with or without AI.
The anatomy of an error
Most errors have three parts:
- The type — what kind of problem:
TypeError,SyntaxError,ModuleNotFoundError,ECONNREFUSED. - The message — a sentence describing it:
Cannot read properties of undefined (reading 'email'). - The location — where it happened, usually as a stack trace: a list of files and line numbers.
TypeError: Cannot read properties of undefined (reading 'email')
at ProfileCard (src/components/ProfileCard.tsx:14:22)
at renderWithHooks (node_modules/react-dom/...)
at mountIndeterminateComponent (node_modules/react-dom/...)
Step 1: find the first line
The first line — type and message — is the most important thing on the screen. Read it slowly. Here it says: something that should have been an object was undefined, and the code tried to read .email from it.
Step 2: find your file in the stack trace
A stack trace lists the chain of calls that led to the error, most recent first. Many lines point into node_modules or framework internals — skip those. Look for the first line pointing to your code:
at ProfileCard (src/components/ProfileCard.tsx:14:22)
That means: file ProfileCard.tsx, line 14, character 22. Open it and look at line 14. It probably says something like user.email — and user is undefined, maybe because the data hasn't loaded yet.
That's often the whole diagnosis: what went wrong (first line) and where (your first file in the trace).
Common errors, translated
| Error | What it usually means |
|---|---|
Cannot read properties of undefined (reading 'x') |
Something you expected to exist doesn't (yet) — data not loaded, wrong name, missing check |
x is not defined |
A name is used but never created — typo, or a missing import |
x is not a function |
You're calling something that isn't a function — wrong name, or wrong import |
Module not found / Cannot find module |
A package isn't installed, or a file path/capitalisation is wrong |
SyntaxError: Unexpected token |
Broken code — a missing bracket, comma, or quote, usually near the line shown |
ECONNREFUSED |
Couldn't connect to something — a database or server that isn't running, or the wrong address |
EADDRINUSE / "port already in use" |
Something is already running on that port — often an old copy of your app |
401 / 403 |
Not logged in / not allowed — missing or wrong API key, or permissions |
404 |
Wrong URL, or the thing doesn't exist |
500 |
The server crashed handling the request — check the server's logs for the real error |
CORS error |
The browser blocked a request from one domain to another — the fix is on the backend |
relation "users" does not exist |
The database table doesn't exist — migrations haven't run |
Step 3: know where to look
Errors appear in different places depending on where the problem is:
- The terminal running your app — server errors, build errors, startup errors.
- The browser console — frontend errors. Right-click the page → Inspect → Console tab.
- The browser Network tab (same panel) — failed requests to your backend or APIs, with status codes. Click a red request to see the response.
- Your host's logs — for the live site. Build logs and runtime logs are usually separate.
"Nothing happens" usually means the error is somewhere you're not looking. A button that does nothing almost always has a red error in the browser console or a failed request in the Network tab.
Step 4: the "what changed?" question
If it worked before, the fastest question is: what changed since then? A new package, a new feature, a changed setting? Git makes this easy — git diff shows exactly what changed since your last save. (Git and GitHub for Beginners.)
Giving an error to an AI
AI tools are very good at fixing errors — if you give them the right information:
- The full error text, copied — not a screenshot, not a summary. Include the first line and the stack trace.
- What you did to trigger it: "clicked Save on the profile page."
- What you expected vs what happened.
- What changed recently, if you know.
- Where it appeared: terminal, browser console, or host logs.
When I click Save on /profile, nothing happens. Browser console shows:
TypeError: Cannot read properties of undefined (reading 'email') at ProfileCard (src/components/ProfileCard.tsx:14:22)This started after we added avatar uploads. Please explain the cause before fixing it.
"Explain the cause before fixing it" is a good habit: it stops the AI from applying a random patch that hides the symptom. And if the same error keeps coming back after several fixes, change approach — see Stuck in an AI Fix Loop?
Searching for errors
Pasting the first line of an error (minus your specific file names) into a search engine often finds someone who hit the same thing. Look for results from the tool's own documentation, GitHub issues, and Stack Overflow.
The summary
- Read the first line — the type and message.
- Find your file and line in the stack trace; skip
node_modules. - Check the right place: terminal, browser console, Network tab, or host logs.
- Ask what changed.
- Give an AI the full text plus what you did and expected.
EasySpawn runs your app and Claude Code side by side, so the agent reads the real error from the running app — not your description of it — and checks its own fix. See how it works or join the waitlist.
Related: Stuck in an AI Fix Loop? · Why Does My App Work Locally but Not in Production? · Browser Developer Tools for Beginners · Debugging for Beginners · File Paths Explained
Keep reading
How to Test Your App Before Launch (Without Writing Tests)
You don't need to be a programmer to find most bugs before your users do. A practical, one-afternoon testing plan for AI-built apps: the journeys to walk through, the 'try to break it' checks, the security tests, and how to keep track of what you find.
HTTP Status Codes Explained: 200, 301, 404, 500 and the Rest
Every response from a server starts with a three-digit number that says how it went. What the 2xx, 3xx, 4xx, and 5xx families mean, the dozen codes you'll actually meet, what each one tells you about where a bug lives, and which ones your own API should return.