Read and manage your server logs

When something’s wrong, the log usually already says what. Knowing where to look — and reading from the bottom (newest) — solves most problems fast.

The logs that matter

Log	Tells you
Web server (nginx)	requests, 4xx/5xx errors, which site was hit
App log	your application’s own errors and stack traces
PHP / php-fpm	fatal PHP errors (the cause of a white screen)
Deploy/build log	why a Git deploy failed
System journal	service starts/crashes, out-of-memory kills

Read them

In the web terminal or SSH:

tail -n 100 app.log          # last 100 lines
tail -f app.log              # follow live (Ctrl-C to stop); reproduce the bug while watching
grep -i error app.log        # jump to errors
journalctl -u SERVICE -n 100 # a systemd service's recent logs

Read bottom-up. The newest lines are the error you’re chasing; scroll up for the context that led to it.

A fast debugging loop

1. tail -f the relevant log.
2. Reproduce the problem in the browser.
3. Watch the error appear in real time — that’s your lead.

Don’t let logs fill the disk

Runaway logs are a classic cause of a sudden “disk full” outage.

• Check sizes: du -sh * in the log directory, and df -h overall.
• Trim the system journal: sudo journalctl --vacuum-time=7d.
• For app logs, use log rotation (most frameworks/servers rotate by default) so old logs are compressed and eventually removed.

See disk & memory for reclaiming space, and monitor resources to catch it early.

---

Running OrbixPanel? App build/deploy logs are viewable right in the panel. OrbixPanel.com → — the free, self-hosted, AI-powered hosting control panel.