10 Linux Commands to Check Server Health Over SSH

When a site slows down or a deploy fails, the first job is to find out whether the server itself is healthy. These ten commands answer that in a couple of minutes. They work on any modern Linux server over SSH, including from a phone, and none of them change anything.

1. uptime: load and uptime

uptime

The three numbers at the end are the load average over the last 1, 5 and 15 minutes. Compare them with the number of CPU cores (nproc). On a 2-core server, a load around 2 is fully busy; 6 means work is queuing. A recent boot time you didn’t expect means the server restarted, perhaps after running out of memory.

2. free -h: memory and swap

free -h

Don’t worry if free is low: Linux uses spare memory as cache. Look at available, which is what programs can still use. If available is near zero and swap is in heavy use, the server is short of memory and will feel slow.

3. df -h: disk space

df -h

A filesystem at 100% breaks databases, logs and uploads in confusing ways. Act on anything above about 90%. Also check inodes with df -i: millions of tiny files can run out of inodes while space remains.

4. du: what is filling the disk

sudo du -xh --max-depth=1 / 2>/dev/null | sort -h | tail

This lists the largest top-level folders. Repeat it inside the biggest one until you find the cause. Usual suspects: /var/log, /var/lib/docker, and old backups. docker system df shows how much Docker images and volumes use.

5. top or htop: what is busy right now

top -o %CPU

Press M to sort by memory and q to quit. If htop is installed, it is easier to read. Look for one process using most of the CPU or memory. That is usually your culprit.

6. systemctl --failed: crashed services

systemctl --failed
systemctl status nginx --no-pager

The first command lists every service that has crashed. The second shows one service’s state and its last log lines, which often contain the error.

7. journalctl: errors in the logs

journalctl -p err -b --no-pager | tail -50
journalctl -u myapp --since "30 min ago"

-p err shows only errors, -b limits it to the current boot, and -u picks one service. Most problems announce themselves here.

8. ss -tlnp: what is listening

sudo ss -tlnp

This lists every TCP port a program is listening on. If your app should be on port 3000 and nothing is there, it isn’t running. If two programs fight over a port, one will fail to start.

9. docker ps: container status

docker ps -a --format "table {{.Names}}\t{{.Status}}"

Look for containers that are Exited or restarting over and over. docker logs --tail 50 name shows why. For apps run by PM2, pm2 ls does the same job.

10. dmesg: kernel warnings

sudo dmesg -T | tail -30

The kernel log shows hardware errors, disk problems, and the out-of-memory killer. A line containing Out of memory: Killed process explains a service that “randomly” died.

Put it together

Run the first four commands every time; they take seconds and rule out the most common problems. Then follow whatever looks wrong:

• High load: top to find the process.
• Low memory: top sorted by memory, then dmesg for the OOM killer.
• Full disk: du to find the folder.
• Service down: systemctl status, then journalctl -u.

If you want help reading the output, an AI agent running on the server can inspect it for you. See how to use Claude Code on a remote server from your phone. And if you are still logging in with a password, fix that first: SSH keys vs passwords.

Questions