# How to troubleshoot anything on your VPS (and where everything logs)
Source: https://vpsdime.com/knowledgebase/troubleshooting/troubleshooting-method
Last reviewed: 2026-07-02
Summary: The general diagnostic method, reproduce, observe, hypothesize, change one thing, the question-to-command table, and the log atlas: where systemd, nginx, Apache, PHP, MySQL, PostgreSQL, Docker, SSH, cron, certbot, mail, and the rest actually write their logs, with the reading techniques (tail -f, journalctl filters, zgrep) that turn logs into answers.

## 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](https://vpsdime.com/knowledgebase/client-area/services/tasks)** (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](https://vpsdime.com/knowledgebase/client-area/services/graphs)**, a resource event (CPU plateau, disk cliff, traffic spike) that coincides with the symptom is rarely a coincidence.

## The question-to-command table

| Question | Command | Deep guide |
|---|---|---|
| Is the service even running? | `systemctl status nginx` | [services after reboot](https://vpsdime.com/knowledgebase/troubleshooting/services-not-starting-after-reboot) |
| What did it say when it died? | `journalctl -u nginx -n 50` | |
| What's eating CPU/memory? | `htop`, `ps aux --sort=-%cpu \| head` | [slow VPS](https://vpsdime.com/knowledgebase/troubleshooting/slow-vps) |
| Is memory actually short? | `free -h` (the **available** column) | [memory](https://vpsdime.com/knowledgebase/troubleshooting/vps-using-too-much-memory) |
| Is the disk full? Inodes? | `df -h` and `df -i` | [disk](https://vpsdime.com/knowledgebase/troubleshooting/disk-full), [inodes](https://vpsdime.com/knowledgebase/troubleshooting/out-of-inodes) |
| What's listening on what port? | `ss -tulnp` | [ports](https://vpsdime.com/knowledgebase/troubleshooting/my-port-xxx-is-closed) |
| Is the network path the problem? | `mtr -rwbzc 100 <ip>` | [network](https://vpsdime.com/knowledgebase/troubleshooting/network-problems) |
| What's happening *right now*? | `journalctl -f`, or `tail -f <logfile>` | |
| What happened at 3 AM? | `journalctl --since "03:00" --until "03:30"` | |
| Was a process OOM-killed? | Linux VPS: [My VPS is Down](https://vpsdime.com/knowledgebase/client-area/support/vps-troubleshooter) reports it (not visible in-guest) | [slow VPS](https://vpsdime.com/knowledgebase/troubleshooting/slow-vps) |

## 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](https://vpsdime.com/knowledgebase/troubleshooting/502-503-errors)) and `access.log` (every request: source IP, URL, status code, [the bot hunt](https://vpsdime.com/knowledgebase/troubleshooting/bot-traffic) 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](https://vpsdime.com/knowledgebase/troubleshooting/ssl-certificate-errors). 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](https://vpsdime.com/knowledgebase/troubleshooting/mysql-wont-start)); the **slow query log** is separate and off by default ([the performance section](https://vpsdime.com/knowledgebase/troubleshooting/slow-vps)).
- **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](https://vpsdime.com/knowledgebase/troubleshooting/cron-not-running)).
- **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](https://vpsdime.com/knowledgebase/troubleshooting/ssl-certificate-errors).
- **Mail (Postfix)**: `/var/log/mail.log`, one line per message with its fate ([inbound](https://vpsdime.com/knowledgebase/troubleshooting/cannot-receive-email) and [outbound](https://vpsdime.com/knowledgebase/troubleshooting/emails-going-to-spam) 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](https://vpsdime.com/knowledgebase/troubleshooting/services-not-starting-after-reboot), `pm2 logs`; a [scheduled script](https://vpsdime.com/knowledgebase/technical-questions/systemd-timers), 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](https://vpsdime.com/knowledgebase/windows-vps/view-save-event-log).)

## 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](https://vpsdime.com/knowledgebase/support-coverage/software-and-server-management)** with one sentence of context, exact error lines are what they're best at.
3. **[Ticket it](https://vpsdime.com/knowledgebase/getting-started/raising-a-support-ticket)**, 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](https://vpsdime.com/open-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?"