Error logs live in 7 places: /var/log (system), the app’s stdout (the platform’s deploy), the platform’s dashboard (Render, Fly, Heroku), the journald journal (for systemd services), the Docker logs (docker logs), the application log file (the team’s app writes to a file), and the cloud provider’s log service (CloudWatch, Stackdriver). The right answer is the platform’s dashboard for production, the journald for systemd services, the stdout for the platform’s deploy. The mistake every team makes: the team greps for the error in the wrong place, the team finds nothing, the team assumes the error did not happen.
Table of contents
- The 7 locations — the actual list
- The tail command — the right answer for live logs
- The grep — the right answer for a specific error
- The journald — the right answer for systemd services
- The Docker logs — the right answer for containers
- The platform’s dashboard — the right answer for production
- The application log file — the right answer for a custom log path
- The one mistake that masks the real error
- How this fits the rest of the stack
- FAQ
The 7 locations — the actual list
The 7 locations for error logs:
- /var/log — system logs (syslog, auth.log, kern.log, nginx/access.log, nginx/error.log).
- The app’s stdout — the platform’s deploy captures stdout, the logs are in the platform’s dashboard.
- The platform’s dashboard — Render’s Logs tab, Fly’s logs, Heroku’s logs, Vercel’s logs.
- The journald journal — journalctl -u myapp.service for a systemd service.
- The Docker logs — docker logs
for a Docker container. - The application log file — the team’s app writes to a file (/var/log/myapp/app.log), the file is rotated by logrotate.
- The cloud provider’s log service — CloudWatch (AWS), Stackdriver (GCP), Azure Monitor (Azure).
The tail command — the right answer for live logs
The right answer for live logs is tail -f /var/log/myapp/app.log. The command streams the new lines as they are written, the team’s terminal is the live log. The right answer is tail -n 100 to see the last 100 lines, the right answer is tail -f | grep ERROR to filter for errors only.
The grep — the right answer for a specific error
The right answer for a specific error is grep -i 'error' /var/log/myapp/app.log. The right answer is -i for case-insensitive, the right answer is -n for line numbers (the team can find the line quickly), the right answer is -B 5 -A 5 for context (5 lines before, 5 lines after).
The journald — the right answer for systemd services
The right answer for a systemd service is journalctl -u myapp.service. The command shows the logs of the service, the right answer is -f to follow (live), the right answer is --since "1 hour ago" for a time range, the right answer is -p err to filter for errors only.
The Docker logs — the right answer for containers
The right answer for a Docker container is docker logs <container>. The right answer is -f to follow (live), the right answer is --since 1h for a time range, the right answer is --tail 100 for the last 100 lines. The wrong answer is to ssh into the container and grep the log file — the team’s log is in the Docker logs, not in the container’s filesystem.
The platform’s dashboard — the right answer for production
The right answer for production is the platform’s dashboard. Render: Logs tab in the service view. Fly: fly logs from the CLI. Heroku: heroku logs —tail. Vercel: Logs tab in the deployment. The right answer is the dashboard for the team’s first debugging step, the right answer for a deeper analysis is to export the logs to a log service (Datadog, Loggly).
The application log file — the right answer for a custom log path
The right answer for a custom log path is the application log file. The team’s app writes to /var/log/myapp/app.log, the team reads with tail -f. The right answer is to set up logrotate to prevent the file from filling the disk, the right answer is to write structured logs (JSON) for easy parsing.
The one mistake that masks the real error
The mistake: the team greps for the error in the wrong place. The team’s app logs to stdout, the team greps /var/log, the team finds nothing, the team assumes the error did not happen. The right answer is to find where the app logs FIRST (the Dockerfile, the platform’s docs, the team’s code), then to grep in the right place.
How this fits the rest of the stack
The infrastructure question is a small piece of a larger pattern: the team’s runtime, storage, database, secret store, logs, and deployment platform are all parts of the same platform. The right answer is to model the full stack before the project ships, not after. The RunxBuild hosting calculator is the right place to do that exercise — pick the runtime, the memory tier, the storage, the secret store, and the egress, and the calculator shows what the deploy actually costs at the team’s actual usage.
Useful related references:
FAQ
Where do I find error logs?
7 places: /var/log, the app’s stdout, the platform’s dashboard, the journald journal, the Docker logs, the application log file, the cloud provider’s log service.
How do I tail a log file in Linux?
tail -f /var/log/myapp/app.log for live, tail -n 100 for the last 100 lines, tail -f | grep ERROR for errors only.
How do I grep for an error in a log file?
grep -i ‘error’ /var/log/myapp/app.log. The right answer is -i for case-insensitive, -n for line numbers, -B 5 -A 5 for context.
How do I see the logs of a systemd service?
journalctl -u myapp.service. The right answer is -f to follow, —since ‘1 hour ago’ for a time range, -p err for errors only.
How do I see the logs of a Docker container?
docker logs
How do I see the logs on Heroku?
heroku logs —tail from the CLI, or the Logs tab in the dashboard.
How do I see the logs on Render?
The Logs tab in the service view in the dashboard, or render logs from the CLI.
What is the difference between stdout and a log file?
stdout is the standard output stream, captured by the platform’s deploy. A log file is a file on disk, the team reads with tail/grep. The right answer is stdout for the platform’s deploy, a log file for a custom log path.