Home / Blog / VPS and Infrastructure / How to Monitor VPS CPU RAM and Disk Usage
A VPS does not send you a warning when it is about to run out of memory or disk space. It simply slows down, starts failing requests, or stops responding — usually at the worst possible moment. Monitoring is how you see the problem coming while there is still time to fix it.
This guide covers the essentials: the commands that show what is happening right now, how to read the numbers correctly, and how to set up ongoing monitoring and alerts so you are warned before a resource problem becomes downtime.
Three scenarios make monitoring non-negotiable:
Monitoring is also how you size correctly. The usage data you collect today is the evidence you need when deciding whether to upgrade — see how to size a VPS for your application.
These commands are available on almost every Linux server and answer the immediate question: is the server under pressure?
top, htop, and freetop shows a live, updating view of CPU and memory usage per process. htop is the same idea with a clearer interface — install it with sudo apt install htop on Debian/Ubuntu or sudo dnf install htop on RHEL-based systems. Sort by CPU or memory to find the process consuming the most.
For memory specifically, free -h gives the overview:
free -h
# total used free shared buff/cache available
# Mem: 3.8Gi 1.9Gi 412Mi 124Mi 1.5Gi 1.6Gi
# Swap: 2.0Gi 0.0Ki 2.0Gi
Read the available column, not free. Linux uses spare memory for disk cache (the buff/cache column), so free is often low on a healthy server. Available is the memory that applications can actually use. If available is close to zero, the server is genuinely short of memory. Any sustained swap usage — the used column under Swap above zero — is a warning sign: the server is already borrowing from disk because RAM is exhausted, and performance will suffer.
uptime and load averagesuptime
# 20:14:03 up 42 days, 3:12, 1 user, load average: 0.85, 0.62, 0.41
The three numbers are the load average over the last 1, 5 and 15 minutes — roughly, how many processes were waiting for CPU. Compare them with the number of CPU cores: on a 2-core server, a load average of 2.0 means the CPUs are fully busy; sustained load above the core count means processes are queuing. A load average that is rising across the three numbers (1-minute higher than 15-minute) means demand is increasing right now.
df and dudf -h
# Filesystem Size Used Avail Use% Mounted on
# /dev/vda1 49G 31G 16G 66% /
Watch the Use% column. A disk that reaches 100% causes immediate failures: databases cannot write, logs cannot rotate, uploads fail, and some services refuse to start. Set an alert well before that point (see below). To find what is using the space, du shows directory sizes:
sudo du -sh /var/* /home/* 2>/dev/null | sort -h
Common culprits are unrotated logs in /var/log, old backups, and runaway cache directories. Never delete files blindly — confirm what a directory contains before removing it, and never delete a live database’s files while the database is running.
iostat and iotopIf the CPU is idle but the server is slow, the disk may be the bottleneck. iostat -x 1 (from the sysstat package) shows how busy each disk is and how long requests wait. High %util combined with high await means the disk cannot keep up — a common problem on older storage, and a reason to prefer NVMe SSDs. iotop shows which process is generating the I/O, the same way top shows CPU.
Numbers without context are noise. Establish a baseline for your server during normal operation, then watch for deviation:
| Metric | Healthy | Investigate |
|---|---|---|
| CPU usage | Usually below 70% at peak | Sustained above 80–90% |
| Load average | Below the core count | Sustained above the core count |
| Memory available | Comfortable headroom | Consistently low; any sustained swap use |
| Disk usage | Below 70% | Above 80%; urgent above 90% |
| Disk I/O wait | Low, occasional spikes | Sustained high %iowait |
| Network | Within the plan’s allowance | Approaching the monthly bandwidth limit |
A single spike is not a problem — backups, updates and cron jobs all cause brief peaks. The pattern to worry about is a sustained change: CPU that used to idle at 20% now sits at 70%, or disk usage climbing steadily week after week. Trends are the signal; spikes are usually noise.
Manual commands are fine for a one-off check, but they do not help at 3 a.m. For ongoing monitoring, you need a tool that records history and sends alerts.
Lightweight, single-server options. Netdata installs in minutes and gives a real-time web dashboard of CPU, memory, disk, network and per-process usage, with built-in alerts. It is a good first monitoring tool for a single VPS: low overhead, no configuration needed to start, and it shows trends as well as current values.
Full monitoring stacks. Prometheus (metrics collection) with Grafana (dashboards and alerting) is the standard combination for larger setups and multiple servers. It takes more effort to set up, but it scales, keeps long-term history, and lets you build alerts such as “notify me if memory available falls below 15% for ten minutes”. If you manage several servers, this is the investment that pays off.
External uptime monitoring. A tool on the server cannot tell you the server is down — because it goes down with it. An external service such as UptimeRobot checks your site from outside at regular intervals and alerts you when it stops responding. This is the simplest and most important monitoring of all: it answers the question “is the site up?” from the visitor’s point of view. Set it up on every production site, with alerts to an email address or messaging channel someone actually reads.
Alerts are only useful if they reach someone who acts on them. A few principles:
Monitoring tools collect the data; a routine makes it useful. Once a week, spend ten minutes on:
That ten minutes is the cheapest insurance a VPS owner can buy. It catches the slow disk fill, the creeping memory leak and the degrading database weeks before they become an outage — and it gives you the data to size your next upgrade with confidence.
Containers package an application with everything it needs, so it runs the same way on any server. This guide explains what Docker containers are, when they help on a VPS, and the basics of running them well.
GPU hosting rents you a server whose graphics processor does the heavy lifting — for AI models, rendering and other parallel work. This guide explains who actually needs it, who does not, and what to check before buying.
A dedicated server gives you the whole machine — and the whole responsibility for it. Know exactly which jobs are yours before you sign, or pay for a managed plan.