How to Monitor VPS CPU, RAM, and Disk Usage in Real Time

When a VPS slows down, the first question is always the same: what is consuming the CPU, RAM, or disk right now? Guessing wastes time — the Linux kernel already tracks every metric you need, and a handful of commands can show you exactly what is happening in real time. This guide covers the commands every sysadmin should know for live CPU, memory, and disk monitoring, plus the point at which you should graduate to a full monitoring stack.

The techniques below work on any Linux VPS regardless of provider. If you are setting up a new server and want hardware that will not bottleneck your workload, compare VPS plans side by side in our comparison table before you commit — real-time monitoring is most useful when the underlying instance is sized correctly in the first place.

CPU: Watch Load and Per-Core Usage

htop gives the best live overview of CPU, memory, and running processes in a single screen, color-coded by type of usage:

sudo apt install htop
htop

For a per-core breakdown and running averages, mpstat from the sysstat package is the classic tool. Run it every two seconds and watch the %idle column:

sudo apt install sysstat
mpstat -P ALL 2

If %idle drops to zero across all cores and the load average stays above the number of vCPUs, the box is CPU-bound. Switch back to htop and look for a runaway process before you spend money on a bigger plan.

RAM: free and vmstat

free -h is the fastest way to see total, used, and available memory:

free -h

Read the available column, not used. Linux caches file data in RAM and reports it as used, but that cache is reclaimed on demand, so a high used value alone is not a problem. vmstat 2 shows memory pressure over time, including swapping:

vmstat 2

Watch the si and so columns. If they are non-zero for more than a few seconds, the system is actively swapping — a reliable sign that physical RAM is genuinely exhausted.

Disk: I/O and Free Space

iostat -x (also from sysstat) reports per-disk utilization, throughput, and average service times:

iostat -x 2

Sustained high %util on an SSD-backed VPS usually means a process is hammering the disk or the provider is throttling I/O. For free space and the largest directories, combine df and du:

df -h
du -sh /var/* 2>/dev/null | sort -h | tail

Combine Everything with Glances

glances bundles CPU, memory, disk, network, and the top processes into one terminal dashboard that refreshes every couple of seconds. It is the closest thing to a GUI without leaving the shell, and it can also export to InfluxDB or send alerts when thresholds are crossed:

sudo apt install glances
glances

Press d inside glances to toggle disk I/O, n for network, and s for sensors. If you prefer a web view, run glances -w and open the dashboard in a browser on port 61208.

Watch Logs in Real Time

Metrics alone rarely explain a fault — logs fill in the why. Follow the system journal and kernel messages as events happen:

journalctl -f -u nginx
journalctl -k -f
tail -f /var/log/mysql/error.log

Alert Thresholds with a Simple Script

For small setups, a cron job that checks a threshold and sends mail is enough. Save this as /usr/local/bin/check-load.sh and make it executable:

#!/bin/bash
LOAD=$(awk '{print $1}' /proc/loadavg)
CORES=$(nproc)
if [ "$(echo "$LOAD > $CORES * 2" | bc)" = "1" ]; then
    echo "High load on $(hostname): $LOAD" | mail -s "VPS load alert" [email protected]
fi

*/5 * * * * /usr/local/bin/check-load.sh

Full Monitoring Stacks

When one server is no longer enough, install Netdata for instant per-second graphs, or Prometheus with node_exporter for long-term metrics, alerting rules, and dashboards. Start with the command-line tools above either way — they work everywhere with zero dependencies and give you the intuition you need to interpret the fancier dashboards later.

Conclusion

Real-time monitoring is a reflex, not a project: htop for processes, vmstat for memory pressure, iostat for disk, and journalctl for logs. Practice them until they are automatic, add a threshold script for the hours you are asleep, and only then consider a full stack. When your workload outgrows the instance, check the full specs and pricing of top providers in our comparison table to plan the upgrade with real numbers in hand.