Most VPS problems fall into four groups, and identifying which one you have takes about a minute. The site is unreachable, the site is slow, a service stopped, or you cannot get in at all. They share almost no causes, so working out which before investigating saves the most time.
First: can you reach the machine
ping 203.0.113.45 ssh [email protected]
If SSH works, the server is running and the problem is a service on it. If it does not, the problem is the machine, the network, or a firewall rule. A different search entirely.
The site is unreachable but SSH works
The web server is not running, or not listening where you expect. Check its status and its error log, in that order.
Three causes account for nearly all of it. A configuration error after an edit. The service refused to restart and is simply stopped. A full disk, which stops services writing and takes them down in ways that look unrelated. The firewall, if rules changed recently.
Check disk first because it is instant and it explains a surprising share of mysterious failures:
df -h
A volume at 100% takes down web servers, databases and mail simultaneously, and none of the resulting errors mention disk.
The site is slow
Find out which resource is short before changing anything.
top free -h df -h
If CPU is saturated, something is doing real work, find the process. If memory is exhausted and the system is swapping, that is usually the actual cause of a server that feels unusably slow rather than merely busy.
If both look idle and it is still slow, you are waiting on disk or network, and no amount of tuning the application will help.
A process was killed with no error
The system ran out of memory and terminated it. The process did not fail; it was stopped.
Check the system log for out-of-memory entries. This is common on smaller instances with database-heavy applications, and the fix is either less memory pressure or more memory, not restarting the service repeatedly.
You cannot log in
Connection refused means SSH is not running or is blocked. If you recently enabled a firewall without allowing SSH first, this is why, and console access from the provider is the way back.
Permission denied (publickey) after key setup means the key is not where the server expects, or its permissions are too open. The .ssh directory must be 700 and authorized_keys 600: SSH refuses more permissive files deliberately.
Timed out is usually the network path. Try from a different connection before assuming the server is down.
Everything broke after an update
Read the log for the service that failed. Package upgrades sometimes replace a configuration file, and the service then refuses to start with a clear message about what it did not understand.
This is exactly what snapshots are for. Taking one before an upgrade turns this from an investigation into a five-minute rollback. Understanding KVM virtualization goes into what a snapshot does and does not protect.
What to check before opening a ticket
Disk usage, memory, whether the service is running, and the relevant log's last twenty lines. Those four answer most questions, and including them turns a long exchange into one reply.
If several unrelated services failed at the same moment, check disk before anything else. It is the single most common cause of a server that appears to have broken in every direction at once.
When a scheduled job stopped running and nothing said so, How to Schedule Jobs with Cron and Systemd Timers deals with why cron fails quietly.
A high load with idle processors is not a contradiction, and knowing why narrows the cause immediately. Understanding Load Average and CPU Steal deals with reading it.
A machine that is unreachable needs a different starting point, because none of these checks can be run. How to Diagnose a Server That Will Not Boot has the detail.
Establish when it started
Before investigating what is wrong, establish when it began, because that determines what to suspect.
uptime last reboot | head -3 grep -iE 'installed|upgraded' /var/log/dpkg.log 2>/dev/null | tail -10 rpm -qa --last 2>/dev/null | head -10
A problem that began at a reboot points at something that does not start automatically. One that began at an update points at the update. One with no corresponding event is more likely growth. A disk filling, a table growing, traffic increasing.
That single question eliminates most of the search space in under a minute, and it is the step people skip in favour of looking at symptoms.
Check the account limits, not just the machine
On a VPS the machine's own limits are only half of it, several ceilings apply per process or per user and produce failures that look like resource exhaustion on a machine with resources to spare.
ulimit -a cat /proc/sys/fs/file-max lsof 2>/dev/null | wc -l sysctl net.ipv4.ip_local_port_range
An application refusing new connections while memory and processor are fine is usually an open-file limit instead of a capacity problem, and raising the machine's specification changes nothing.
The same applies to port exhaustion on a server making many outbound connections: a narrow range runs out under load and produces intermittent failures with no obvious cause.
Rule out the parts you did not write
Where the fault is intermittent and nothing correlates, the layers below the application are worth eliminating.
dmesg -T | tail -30 journalctl -p err -b --no-pager | tail -20
The kernel ring buffer records what nothing else does: a process killed for memory, a disk error, a network interface resetting, a filesystem remounting read-only.
A filesystem that has gone read-only is the one worth recognising immediately. The machine keeps running, everything that writes fails, and no application log explains it because the log cannot be written either.
Capture the state while it is wrong
Intermittent problems are diagnosed from evidence collected during the fault, and by the time anyone looks it has usually passed.
#!/bin/sh d=/root/diag/$(date +%F-%H%M%S); mkdir -p "$d" uptime > "$d/uptime"; ps auxf > "$d/ps"; ss -tunap > "$d/ss" free -m > "$d/free"; df -h > "$d/df"; dmesg -T | tail -100 > "$d/dmesg"
Triggered by monitoring when a threshold is crossed, that captures what the machine was doing at the moment rather than afterwards.
It is the difference between diagnosing a recurring fault on the second occurrence and waiting for a third. Managing VPS resources and monitoring performance sets out the continuous record alongside it.