Console Errors vs. Network Failures: How to Tell Them Apart

Why the distinction matters

Frontend bugs and backend bugs require different people, different debugging tools, and different fixes. Routing a backend API failure to a frontend developer wastes an hour. Routing a JavaScript TypeError to a backend engineer wastes another.

A bug report that includes both the console output and the network trace gives your team the information to route immediately — without a triage meeting.

Console errors: JavaScript layer problems

Console errors are generated by the browser's JavaScript engine. They indicate that something went wrong in the code running on the page — not necessarily in communication with the server.

Common console error patterns

• TypeError: Cannot read properties of undefined — code tried to access a property on a value that was null or undefined. Usually a frontend data-handling bug.
• ReferenceError: X is not defined — a variable or function wasn't imported or wasn't in scope. Usually a build/bundling or import issue.
• SyntaxError — a malformed JSON response being parsed, or actual JS syntax errors (rare in production builds).
• Uncaught Error / Promise rejection — an unhandled async failure. Could be network-originated (fetch rejected) or entirely local.

A TypeError: Cannot read properties of undefined (reading 'amount') immediately after a successful API call usually means the frontend expected a different data shape than the API returned. That's a contract bug — frontend and backend both need to look at it.

Network failures: communication layer problems

Network failures appear in the Network tab — not always in the console. They indicate that a request to a server didn't go as expected.

Reading status codes

• 4xx errors — the client did something wrong. 400 = bad request (check the request body), 401 = not authenticated (check auth state), 403 = not authorized (permissions issue), 404 = endpoint doesn't exist, 429 = rate limited.
• 5xx errors — the server did something wrong. 500 = internal server error (check server logs), 502/503 = server is down or overloaded, 504 = timeout.
• CORS errors — appear in the console as a network error but are actually a configuration issue on the server side. The request may have succeeded; the browser is blocking the response.
• ERR_NETWORK / Failed to fetch — the request never reached the server. Firewall, DNS, offline device, or the server URL is wrong.

The most commonly confused case: 500 with a helpful body

When a server returns 500, the console might show "Uncaught Error" or display a red network entry — but the real information is in the response body. {"error": "invalid_amount"} tells you exactly what went wrong. Without capturing the response body, you only know it failed; you don't know why.

When both appear together

A network failure often triggers a cascade of console errors. The API call fails with a 500, the JavaScript tries to access response.data.user.id, and response.data is null because the error handler didn't account for that response shape — so you get a TypeError on top of the network failure.

In this case, the console error is a symptom of the network failure. Fixing the network error will fix the console error. Knowing which is the cause saves time.

How to tell them apart in a bug report

Look at the timestamp sequence

If a console error fires immediately after a network request, the network request is probably the cause. If the console error fires first, it's a standalone JavaScript problem.

Look at the error message

Failed to fetch or Network request failed — network layer.
TypeError, ReferenceError — JavaScript layer.

Look at the Network tab

Is there a red entry? What's the status code? What did the response body say?

What to include in a bug report

For any broken interaction, include both:

• The full console output (all levels, not just errors)
• The network request that failed — method, URL, status, request body, response body

Together, these two artifacts answer almost every triage question without a meeting. Site Reviewer captures both automatically with every report.