How to Monitor Server CPU, RAM, and Disk Usage

Check current usage in one command

Run top or htop for CPU, free -h for RAM, and df -h for disk — those three commands give you a complete snapshot in under ten seconds, with no extra installs required on a stock Ubuntu 24.04 server.

top refreshes every few seconds and shows per-process CPU and memory consumption, plus the load average in its header. htop is a friendlier drop-in replacement that adds scrolling, color-coded per-core meters, and the ability to kill a process interactively; install it with sudo apt install htop if it isn't already on the box.

free -h reports memory in human-readable units. The column that actually matters is available, not free — Linux deliberately uses spare RAM for disk cache and buffers, so a low free value alongside a healthy available value is completely normal, not a warning sign.

df -h shows disk usage per mounted filesystem in gigabytes. Watch the / and /var mounts specifically, since logs and package caches tend to grow there first.

Watching CPU load over time

Load average is the number of processes waiting for CPU time, averaged over 1, 5, and 15 minutes — and it only means something in relation to how many CPU cores the server has.

A load average of 4.0 is idle on a 16-core box and a serious bottleneck on a single-core VPS. Check core count with nproc, then compare: sustained load above the core count means processes are queuing for CPU time rather than running immediately.

uptime prints the three load averages in one line. For a live view of what's actually happening — user time, system time, iowait, and context switches — run vmstat 1 5, which samples every second for five seconds.

For historical data beyond what top can show you after the fact, install sysstat: sudo apt install sysstat, then enable it in /etc/default/sysstat by setting ENABLED="true" and restarting the service. Once it's running, sar -u 1 5 gives a live five-sample CPU breakdown, and sar -f /var/log/sysstat/sa23 (substituting the day-of-month file you need) replays a full day's history — useful for confirming a spike happened at 3 a.m. rather than guessing.

Tracking memory usage accurately

free -h's available column — not free — is the number that tells you whether a server is actually short on memory; everything else is Linux using idle RAM productively.

The buff/cache column is memory Linux is using for disk buffers and page cache. It gets reclaimed instantly the moment an application actually needs it, so a server showing 200MB free and 6GB in buff/cache is not low on memory — check available instead.

Swap is the real signal worth watching. Run free -h and look at the Swap line, or use swapon --show to see configured swap devices and how full each one is. A little swap usage that stays flat is fine — it might just be inactive pages Linux moved out proactively. Steadily climbing swap usage combined with si/so activity (swap in/out) in vmstat 1 5 means the server is genuinely under memory pressure and is actively paging, which shows up as sluggish response times for anything running on it.

Monitoring disk space and inodes

df -h tells you how much disk space is free, but it can't warn you about the other way a filesystem fails: running out of inodes while gigabytes of space remain untouched.

Every file and directory consumes one inode regardless of its size, and ext4 filesystems allocate a fixed number of inodes at creation time. Run df -i alongside df -h — if IUse% is near 100% while Use% from df -h looks fine, you have an inode exhaustion problem, not a space problem. This is common on WordPress sites with huge media libraries or caching layers that create thousands of tiny files.

Once you know a mount is filling up, find the culprit with du -sh /path/* | sort -rh | head, which lists the largest subdirectories under a path, sorted from biggest to smallest. Point it at /var/www, /var/log, and /home first — those three account for most disk growth on a typical LAMP or LEMP server.

Automating checks with a script and cron

A short bash script checking df and free against thresholds, wired into cron, catches a full disk or a memory leak before it takes the server down — and it costs nothing to run every few minutes.

The script below checks root disk usage and available memory percentage, and appends a warning line to a log file whenever either crosses a threshold — swap the echo lines for a mail command or a webhook call if you want an actual alert instead of a log entry. Save it as /usr/local/bin/resource-check.sh, make it executable with chmod +x, then add it to root's crontab with crontab -e to run every five minutes.

This isn't a replacement for proper alerting, but it's a real safety net you can have running in five minutes on any server, with nothing more than bash and cron.

Watching metrics without SSH

Every command above works, but running them means opening a terminal, remembering the syntax, and checking each server one at a time — CloudStick's dashboard shows the same data as a live graph, with zero SSH required.

When you connect a server to CloudStick, the agent installer sets up Zabbix Agent 2 automatically alongside the rest of the CloudStick stack. From that point on, the dashboard's Server Stats panel shows real-time CPU, memory, and disk graphs for every connected server, refreshed continuously rather than sampled on demand — and it's available on every plan, including the Free tier, not gated behind a paid add-on.

That means the exact workflow in this article — checking current load, watching memory trends, confirming disk headroom — is available from a browser tab across your whole fleet, without SSHing into each box individually or remembering which server had sysstat installed. If you're managing more than one or two servers, that difference compounds fast: instead of running df -h on five boxes in five terminal tabs, you get one dashboard.

Your next step: connect a server to CloudStick and open its Server Stats panel — the CPU, RAM, and disk graphs described in this article are already there, live, the moment the agent finishes installing.