Logs and Debugging

Production debugging starts with evidence. Logs answer what happened, when, and often why.

journalctl -u nginx -f
journalctl -u my-app --since "1 hour ago"
sudo tail -f /var/log/nginx/error.log

Check resources too:

df -h
free -m
systemctl status my-app

Further Learning

• “journalctl examples” — querying systemd logs
• “Nginx access error logs” — proxy debugging
• “Linux out of disk debug” — common server failure

Logs and Debugging

When something’s wrong on a server, logs are your evidence — they tell you what happened, when, and often why. Debugging production issues almost always starts with reading them.

Watching logs live

journalctl -u my-app -f          # follow your app's logs in real time
journalctl -u nginx --since "1 hour ago"   # nginx logs from the last hour
sudo tail -f /var/log/nginx/error.log      # nginx's error log specifically

The -f flag means “follow” — new log lines appear as they happen, so you can watch what happens as you reproduce a bug.

Is the app broken, or the proxy?

If a request fails, check both layers separately: your app’s own logs, and Nginx’s logs. Sometimes the app is fine but Nginx can’t reach it (a proxy problem); sometimes the app itself is erroring (an app problem). Checking both tells you which.

Check the basics too

df -h              # is disk space running out?
free -m             # is memory running low?
systemctl status my-app   # is the service even running?

A surprising number of “mysterious” production issues turn out to just be a full disk.

Never log secrets

In one sentence

Debugging starts with logs — follow your app’s and your proxy’s logs separately while reproducing the issue, check basic resources (disk/memory), and never let secrets end up in a log line.

Want to go deeper?

Switch to Expert mode above for detailed journalctl querying and separating proxy errors from app errors.