How to troubleshoot anything on your VPS (and where everything logs)

What this is#

The general method behind every specific guide in this category, and the reference half nobody memorizes: where each popular piece of software writes its logs, and how to read them. Almost every server mystery ends the same way, someone finally opens the right log and the answer is sitting there in plain text. This page shortens the "finally".

The method#

Troubleshooting is a discipline, not a talent:

1. Reproduce it. A problem you can trigger on demand is half-solved; "it happens sometimes" means your first job is finding the trigger (or a timestamp).
2. Observe before changing anything. Logs, resource state, what's listening, gather the evidence first. Changes made before observation destroy the crime scene.
3. Check what changed. Problems rarely appear from nothing. Two tools answer "what changed?" without relying on memory: the panel's Tasks tab (every panel action, timestamped, including ours) and /var/log/apt/history.log (every package installed or upgraded, and when). Line those up against when the trouble started.
4. Form a hypothesis, change one thing, re-test. One. Changing three things that "might help" leaves you not knowing which one did, or which one broke something else.
5. Match the timing against Graphs, a resource event (CPU plateau, disk cliff, traffic spike) that coincides with the symptom is rarely a coincidence.

The question-to-command table#

The log atlas#

Start with the journal. On systemd distros (all our images), most services log to the journal first, and journalctl -u <service> is the universal opener. The classic files below still exist for most of these and are what web tutorials reference; both views show the same events.

• The system itself: journalctl (everything), or the classic files, /var/log/syslog (Debian/Ubuntu) / /var/log/messages (RHEL-family).
• Logins and SSH: /var/log/auth.log (Debian/Ubuntu) / /var/log/secure (RHEL), every login, sudo, and failed attempt; journalctl -u ssh for the daemon itself.
• nginx: /var/log/nginx/error.log (why something failed, the 502 decoder) and access.log (every request: source IP, URL, status code, the bot hunt lives here).
• Apache: same pair under /var/log/apache2/ (Debian/Ubuntu) or /var/log/httpd/ (RHEL).
• Caddy: everything goes to the journal, journalctl -u caddy, including the automatic-HTTPS/ACME conversation when a certificate won't issue. Per-site access logs are opt-in (a log directive in the Caddyfile, typically to /var/log/caddy/) and written as structured JSON, pipe through jq for comfortable reading.
• PHP / PHP-FPM: the gotcha, PHP application errors usually land in the web server's error log (or the FPM pool's log, /var/log/php8.2-fpm.log), not a "php.log". A white page with nothing in nginx's error log usually means log_errors is off in php.ini.
• MySQL / MariaDB: /var/log/mysql/error.log or journalctl -u mariadb (the won't-start guide); the slow query log is separate and off by default (the performance section).
• PostgreSQL: /var/log/postgresql/postgresql-*.log.
• Docker: per-container, docker logs <name> (-f to follow, --tail 50), and docker compose logs for a stack. The daemon itself: journalctl -u docker.
• cron: grep CRON /var/log/syslog or journalctl -u cron, proof of whether a job fired at all (the cron guide).
• fail2ban: /var/log/fail2ban.log, every ban and unban.
• certbot / Let's Encrypt: /var/log/letsencrypt/letsencrypt.log, the full ACME conversation when renewal fails.
• Mail (Postfix): /var/log/mail.log, one line per message with its fate (inbound and outbound both end up here).
• Redis: /var/log/redis/redis-server.log.
• ufw: /var/log/ufw.log (blocked packets, when logging is on).
• WordPress: wp-content/debug.log, but only after enabling it (WP_DEBUG + WP_DEBUG_LOG in wp-config.php); otherwise its errors surface in the PHP/web-server logs above.
• Your own apps: under systemd, journalctl -u yourapp; under pm2, pm2 logs; a scheduled script, wherever you pointed its output, which is why you point it somewhere.

(Windows VPS: the equivalent atlas is the Event Log, viewing and saving it.)

Reading techniques#

• Follow live while reproducing, the single most productive move: tail -f /var/log/nginx/error.log in one terminal, trigger the problem in another, watch the line appear. journalctl -f for journal-based services.
• Filter by severity and time: journalctl -p err -b (errors since boot), journalctl -u nginx --since "1 hour ago".
• Search: grep -i error file, and for rotated logs (.gz files logrotate left behind), zgrep searches them without unpacking. less +G file opens a big log at the end.
• Trust timestamps over memory. Correlate the log line's time against the Tasks tab, Graphs, and your own actions, "it broke at 14:02 and apt upgraded PHP at 14:01" closes cases.
• Read the line before the error too. The error is often the symptom; the line above it is often the cause.

When you've found the line#

A specific error line is the most valuable object in troubleshooting, three good moves, in order of speed:

1. Search it verbatim (quoted, minus your hostname/paths), most error strings have been solved publicly.
2. Hand it to an AI chatbot with one sentence of context, exact error lines are what they're best at.
3. Ticket it, and note the line is the machine output the ticket guide asks for: paste it exactly, with the timestamp and what you were doing.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• the exact log line or error you found, with its timestamp,
• what you were doing (or what changed) when it started.

Related questions#

• "Where are the log files on my VPS?"
• "Where does nginx / MySQL / PHP / Docker log to?"
• "How do I watch a log live while reproducing a problem?"
• "How do I see what changed on my server recently?"
• "How do I search old rotated logs?"
• "What's the general method for debugging a server problem?"