What Are Logs? How to Read Them When Your App Breaks
Your app is deployed and running but something is wrong. It is showing an error, behaving unexpectedly, or just refusing to work for a specific user. You built…
Your app is deployed and running but something is wrong. It is showing an error, behaving unexpectedly, or just refusing to work for a specific user. You built it with Claude, ChatGPT, Cursor, or Bolt, and it worked perfectly in testing. Now it is live and broken and you have no idea what is happening inside it. This is exactly what logs are for, and knowing how to read them is the single most useful skill you can develop after getting your first app live.
Logs are your app talking to you. Here is how to listen.
What Logs Actually Are
A log is a running record of everything your app does: every request it receives, every action it takes, every error it hits. Your app writes these records automatically as it runs, in real time, whether you are watching or not.
Think of logs like a flight recorder on an aeroplane. The plane does not wait for a crash to start recording. It captures everything continuously. When something goes wrong, investigators do not guess what happened. They read the recorder. Logs work exactly the same way. When your app breaks, you do not need to guess. You read the logs.
Every hosted app produces logs. The difference between developers who fix problems quickly and non-technical builders who feel stuck is usually just knowing where the logs are and what to look for.
Where to Find Your Logs
Every hosting platform has logs. Here is exactly where to find them:
Vercel: go to your project dashboard, click the deployment, then click the Functions or Runtime Logs tab. For live traffic logs click the Logs section in the left sidebar of your project.
Netlify: go to your site dashboard, click Functions for serverless function logs, or check the Deploy log for build-time issues.
Railway: click your service, then click the Logs tab. Railway shows real-time logs as your app runs so you can watch them update live as requests come in.
Render: click your service, then click Logs in the left sidebar. Render also lets you filter logs by time, which is useful for finding when a specific problem started.
Replit: the console panel at the bottom of the editor shows your app’s output and errors in real time while it runs.
What Logs Actually Look Like
A typical log entry looks something like this:
2026-06-18T08:42:31.204Z INFO Server started on port 3000
2026-06-18T08:43:15.891Z INFO GET /dashboard 200 OK
2026-06-18T08:43:22.447Z ERROR Cannot read property 'email' of undefined
2026-06-18T08:43:22.451Z ERROR at getUserData (/app/routes/dashboard.js:47)
Reading left to right each line has: a timestamp, a severity level, and a message.
Timestamps tell you when something happened. Useful for matching a log entry to a specific user complaint. If someone says “it broke at 8:43am,” that timestamp points you straight to the relevant lines.
Severity levels tell you how serious the entry is:
- INFO: normal activity, everything working as expected
- WARN: something unusual happened but the app kept running
- ERROR: something failed. This is what you are looking for.
The message tells you what happened. ERROR messages are almost always the ones that matter.
How to Read Logs When Something Is Wrong
The process is simple:
Find the first ERROR. Scroll through the logs to the time when the problem started and look for the first line marked ERROR. Everything after it is often knock-on failures from that original error. Fix the first one and the rest usually disappear.
Read the error message literally. “Cannot read property ‘email’ of undefined” means the app tried to access the email field of something that did not exist, probably a user object that was empty or missing. The message is rarely cryptic once you read it as a plain English description of what went wrong.
Note the file and line number. Most errors include where in your code they happened. “at getUserData (/app/routes/dashboard.js:47)” means line 47 of dashboard.js. That is exactly where to look.
Check the timestamp against when users reported the problem. If a user says “it broke around 8:43am,” filter your logs to that time. The relevant error will be right there.
The Fastest Way to Use Logs Without Understanding Them
You do not need to become a log-reading expert. You just need to know how to use them as input for your AI.
Copy the relevant log section, especially any ERROR lines and the lines immediately around them, and paste into ChatGPT, Claude, or Gemini. Type: “My app is broken. Here are the relevant log entries. What went wrong and how do I fix it?”
The AI reads logs fluently. It will identify the root cause, explain it in plain English, and give you the exact fix. This works for virtually every log-based problem you will encounter as a non-technical builder.
The One Thing to Remember
Logs are your app’s running record of everything it does: every request, every action, every error. When something breaks, the answer is almost always in the logs. Find the first ERROR line, note the timestamp and the message, and paste it into your AI. You do not need to understand logs yourself. You just need to know where to find them and where to take them.
Want your app running with fewer things to debug in the first place? → Snapdock
New here? These might help: “Build Failed.” What it means and how to fix it. → I changed one thing and now my app is broken. How do I fix it? →