How to Read Errors and Logs — Where to Look and What to Report

This article covers how to read error messages and logs.

The text that appears when execution stops and the records left behind while a program is running are two different things.

From the single event "an error appeared", where you look splits into three places.

The top two are text that appears when execution stops; the bottom one is a record left behind while the program is running.

When execution stops, an error message and a stack trace appear

When an error — execution stopping because the instructions cannot continue — occurs, the runtime writes out what happened as text.

That text splits into two parts with different roles.

When you run app.js of the booking app my-app with node app.js, this text appears at the point it stops.

/Users/you/my-app/app.js:5
  return items.price * items.count;
               ^

TypeError: Cannot read properties of undefined (reading 'price')
    at keisan (/Users/you/my-app/app.js:5:16)
    at goukei (/Users/you/my-app/app.js:9:10)
    at Object.<anonymous> (/Users/you/my-app/app.js:13:13)
    at Module._compile (node:internal/modules/cjs/loader:1356:14)

The single line starting with TypeError is the error message, and the four lines below starting with at are the stack trace.

That one error message line also splits into three: the type, the description, and the target.

The innermost part, the error type — a name the runtime provides for the category of problem — changes where you look first depending on the name.

The text tells you what happened and where

The red text on screen is made of two things: an error message that states briefly what happened, and a stack trace that lists where it stopped.

Read the error message as three parts — type, description, and target — and once you know the type name, you can tell where to open next.

A stack trace is the list of places passed through before stopping

A program is divided into units of processing, and one unit calls another as it goes.

Each listed line is a unit of processing that was still in progress when it stopped.

Lines higher up are further in; lines lower down are further out.

The keisan line is where it stopped, but all that is there is an expression using the value it received.

Following the value that was passed leads you to line 13, the outermost line.

What was passed there does not contain price, so it stopped when keisan tried to read it.

The listed lines also show file names other than the app.js you wrote.

Start by opening the line for a file you wrote yourself.

The order and the wording differ by runtime.

Python writes File instead of at, and calls the whole listing a traceback — another name for a stack trace.

The listed lines are calls from the inside out

A stack trace is the list of where execution stopped and the places it passed through to get there.

One line is one unit of processing, and the higher it is the further in it sits; the wording and the direction differ by runtime, but in every case you start reading from the line that shows a file name you wrote.

A log is a record of what happens while a program runs, with times

You can read the text shown so far on screen only when you run the program on your computer.

On a public server it is not shown on the user's screen, because showing it gives attackers a clue.

What appears in the right column is the log — a record of what happens while a program runs, written out with the time.

Not only errors: requests that came in and processing that succeeded are also listed one line at a time, in the order they happened.

After a report that a booking cannot be saved, you open the my-app log.

Around that time, these three lines were listed.

2026-09-03 10:12:04  INFO   accepted booking registration id=182
2026-09-03 10:12:05  ERROR  failed to save the booking id=182
2026-09-03 10:12:05  ERROR  connection to the database timed out

Within one line, too, things are laid out in a fixed order: time, log level, and content.

The log level in the middle — the category showing how serious the event on that line is — lets you pull out and read only the serious lines.

The names and the number of categories differ by library, but they share this: they are ranked from light records to serious ones, and a setting decides from which level up you keep them.

Server logs are written out to a file, or sent to a log collection service to be kept.

Reading just the end of a file is covered in Viewing file contents — cat / head / tail / wc.

Where you look is decided by which side stopped.

If it stopped in the box on the left, look at the browser console; if it stopped in the box on the right, look at the server log.

After release, what you read is the log

The text that appears on screen on your computer is kept in the server log after release.

A log line runs time, log level, then content, so once you find the ERROR line, read the lines around it to see what was happening.

When you ask, report 4 things: the full text, the steps to reproduce, the environment, and the time

If you only say "an error appeared", the person answering has to start by asking you back.

They cannot see your computer, so the deciding factor is whether they can create the same state on their own machine.

The second item, steps to reproduce — the sequence of actions that creates the same state again — is the first thing the person answering asks for.

List in order which screen you were on, what you typed, and what you pressed, and add whether it happens every time.

Paste the four as one block rather than sending them separately.

Before you paste, check that no connection host names or API keys are mixed in.

Sometimes nothing works as expected even though no error text appears.

The screen stays blank and nothing happens, or a result comes out but the value is wrong.

In these cases, look for where in the log the records stop.

With all 4, the other person can create the same state

Report four things: the full text that appeared, the steps to reproduce, where you ran it, and the time it happened.

Every one of them is needed for the person answering to create the same state again, so paste the text as it is without cutting it, and before you paste, just check that no secret values are mixed in.