VPS Monitoring: The 5 CPU, RAM, and Disk Metrics That Predict Outages

Most VPS monitoring guides hand you a list of every metric that exists and call it a day. The result is dashboards full of green lines that tell you nothing until the site is already down. This guide takes the opposite approach: here are the specific CPU, RAM, and disk metrics that predict problems on a small virtual server, the exact commands to read them, and the thresholds that should make you act. Start with a VPS plan that gives you room to monitor — resource ceilings on tiny instances make every threshold tighter.

CPU: Ignore Load Average, Watch Steal and iowait

On a VPS, plain CPU utilization is the least useful number. Two metrics matter far more:

• %steal — time your vCPU waits while the hypervisor runs other tenants. Consistently above 5–10% means noisy neighbors; above 20% means your “guaranteed” CPU is fiction.
• %iowait — time the CPU waits on disk. Above 10–15% sustained, your bottleneck is storage, not compute.

# One-shot view (top line: us, sy, wa, st)
top -bn1 | head -5

# Continuous view, 5-second samples
mpstat -P ALL 5

# Or vmstat: 'wa' = iowait, 'st' = steal (last two columns)
vmstat 5

Load average deserves a special warning: on a 2 vCPU instance, a load of 4.0 sounds alarming but is often just a few threads in a brief syscall storm. Always cross-check load against %steal and runnable thread count (procs r in vmstat) before panicking.

RAM: The available Column Is the Only Truth

As covered in memory tuning, free will mislead you — Linux fills unused RAM with page cache by design. The metric that matters is available, and the metric that predicts OOM kills is si/so (swap in/out) in vmstat:

free -h
# available should stay above ~10-15% of total for comfort

vmstat 5
# si/so columns: sustained nonzero swap-in (si) = thrashing

Set your alert at: available < 10% of total RAM for 5+ minutes, or any sustained swap-in activity. That combo is the classic precursor to an OOM kill on a 1–2 GB instance.

Disk: Latency Beats Utilization

Disk %util on a cloud VPS is frequently 100% even when nothing is wrong — many providers’ virtual disks report the host queue as saturated. The numbers that reflect your actual experience are await and svctm-style latency from iostat:

iostat -x 5

# Read: %util, await (ms), and w_await
# Healthy SSD-backed VPS: await under ~10-20 ms under load
# NVMe-backed: under ~2-5 ms
# Sustained await above 50 ms = real storage bottleneck

Also watch iostat for the ratio of reads to writes. A database box with 90% reads should be tuned differently (more cache, read-ahead) than one with 90% writes (bigger journal, different scheduler).

Put It on a Dashboard with Netdata

Manual commands are fine for diagnosis, but you need history to spot trends. Netdata is the fastest way to get a real-time dashboard on a small VPS — it installs in one command, uses ~100 MB RAM, and surfaces exactly the metrics above with sane defaults:

curl -Ss https://get.netdata.cloud | sh
sudo systemctl enable --now netdata
# Dashboard: http://YOUR_VPS_IP:19999
# Metrics: cpu.steal, cpu.iowait, mem.available, disk.await

For alerting without another daemon, a cron job plus curl to a webhook is enough to start — the goal is a page when %steal or await breaches your threshold, not a prettier graph.

Thresholds Cheat Sheet

Metric	Command	Act when
CPU steal	mpstat -P ALL 5	> 10% sustained
CPU iowait	vmstat 5	> 15% sustained
Memory available	free -h	< 10% of total
Swap-in activity	vmstat 5 (si)	any sustained value
Disk await	iostat -x 5	> 20 ms (SSD), > 50 ms (any)

What the Metrics Tell You About Your Plan

Here’s the part most monitoring guides skip: your metrics are also a report card for your provider. Chronic %steal means the host is oversubscribed — no guest tuning fixes it, and the fix is a provider with dedicated cores or better overcommit ratios. Persistent await over 20 ms on an “SSD” plan means the storage tier isn’t what you paid for. When your dashboard says the plan is the problem, compare VPS providers on our comparison table to see real CPU models and storage types side by side before spending another month on a contended host.

If monitoring keeps flagging the same bottleneck and you want infrastructure where those thresholds are rarely hit, InterServer’s VPS plans include dedicated-core options that eliminate steal entirely. Prefer managed so the platform handles this monitoring for you? Cloudways plans ship with built-in server monitoring and alerts.

Stop watching every graph. Track steal, iowait, available memory, swap-in, and disk await; alert on the thresholds above; and let the data tell you whether the fix is a config change or a provider change. That’s the difference between monitoring that fills dashboards and monitoring that prevents outages.

A Minimal Alert Script to Start With

Before you stand up a full alerting stack, a 10-line cron job catches the emergencies. This one checks CPU steal and available RAM and fires a webhook when thresholds are breached — adapt the URL to Slack, Telegram, or a simple mail command:

#!/bin/bash
# /usr/local/bin/vps-health-check.sh — run every 5 min via cron
STEAL=$(mpstat 1 1 | awk '/Average/ {print $NF}')
AVAIL=$(free -m | awk '/^Mem:/ {print $7}')
if (( $(echo "$STEAL > 10" | bc -l) )) || (( AVAIL < 200 )); then
  curl -fsS -X POST -H 'Content-Type: application/json' \
    -d "{\"text\":\"VPS alert: steal=${STEAL}% avail=${AVAIL}MB\"}" \
    https://hooks.example.com/YOUR_WEBHOOK
fi

Add it to cron with */5 * * * * /usr/local/bin/vps-health-check.sh and you have actionable alerting in five minutes — no agent, no dashboards, no monthly fee. Upgrade to Netdata or Prometheus when the single-host script stops being enough.