System Monitoring Commands Every Self-Hoster Should Know

Self-hosting problems fall into four categories: the disk is full, the memory is exhausted, the CPU is pegged, or a service has crashed. Four commands tell you which one is happening in under 30 seconds. Here they are, with the exact flags you need.

df — Is the Disk Full?

The most common self-hosting outage is a full disk. Docker images accumulate. Logs grow. Backups fill up. df shows you every mounted filesystem and how full it is:

df -h

Output:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   42G  5.4G  89% /
/dev/sdb1       200G   89G  111G  45% /opt/stacks

When a filesystem exceeds 90 percent, Docker starts failing to write container logs. At 95 percent, containers may refuse to start. At 100 percent, everything stops. Set a monitoring alert at 80 percent and clear space before you reach 90.

du — What Is Using All the Space?

df tells you the disk is full. du tells you what filled it:

du -sh /var/lib/docker/* 2>/dev/null | sort -h
# Shows the size of each Docker data directory, sorted smallest to largest

Common space hogs:

# Docker images and containers
docker system df

# Docker build cache (can be safely cleared)
docker builder prune -a

# Unused Docker objects (images, containers, volumes, networks)
docker system prune -a

free — Is the Server Out of Memory?

free -h

Output:

              total        used        free      shared  buff/cache   available
Mem:            15G        8.2G        1.1G        234M        6.1G        6.5G
Swap:          2.0G        256M        1.7G

Look at the available column, not free. Linux uses free memory for disk caching, so free will always be low on a healthy system. Available is what matters: it is the memory that can be allocated to new processes. When available drops below 1GB, the system will start killing processes (OOM killer) to stay alive.

top — What Is Using the CPU and Memory?

top

Top shows a live-updating list of processes sorted by CPU usage. The header shows load averages (1, 5, and 15 minutes). A load average equal to your CPU core count means the system is fully utilised. Higher means processes are queuing. Lower means headroom.

# Alternative: htop (if installed) provides a colour interface
sudo apt install htop
htop

ps — Which Processes Are Running?

ps aux | grep nginx      # find all nginx processes
ps aux --sort=-%mem | head -10   # top 10 processes by memory usage

systemctl — Is a Service Running?

systemctl status docker       # check Docker daemon status
systemctl status nginx        # check web server status
systemctl is-active docker    # returns "active" or "inactive"

For systemd-managed services (like Docker itself), systemctl tells you whether the service is running, how long it has been up, and the last few log lines.

journalctl — What Do the Logs Say?

journalctl -u docker -n 50      # last 50 lines of Docker daemon logs
journalctl -u docker -f         # follow Docker daemon logs live
journalctl --since "10 minutes ago"  # logs from the last 10 minutes

Systemd services log to the journal. Docker container logs are separate (docker logs container-name). Application logs inside containers are separate (docker exec container-name tail -f /var/log/app.log). Know which log source you need before you start troubleshooting.

The 30-Second Health Check

SSH into your server and run these four commands. You will know within 30 seconds whether the problem is disk, memory, CPU, or a crashed service:

df -h | head -5           # disk space
free -h                   # memory
top -bn1 | head -5        # CPU load (snapshot, not interactive)
systemctl is-active docker # is Docker running?

If all four look healthy and the problem persists, it is an application-level issue: a misconfigured reverse proxy, an expired SSL certificate, or a container that starts but does not work. Those require application-specific debugging.

VPS1 monitors all of this for you. We set alerts at 80 percent disk usage, 90 percent memory usage, and sustained high CPU. You know about problems before they become outages.