# How to monitor VPS CPU, RAM and network usage on Linux

URL: https://cloudj.net/blog/monitor-vps-resources
Published: 2026-11-11 · Updated: 2026-11-11

> Learn how to monitor VPS CPU, RAM, disk and network with console graphs, htop, vmstat and iostat, set simple alerts, and know when to resize.

When a server feels slow, you need numbers instead of guesses. This guide shows how to monitor VPS resources at three levels: the graphs in the Cloudj console, the standard Linux command-line tools, and a few small scripts that alert you before a problem becomes an outage. It ends with a short decision guide on when to tune, when to resize, and when to move the workload somewhere else.

## Monitor VPS health from the console graphs

Every Cloudj server page in the [console](https://app.cloudj.net) shows CPU, RAM and network metrics. These graphs are the quickest way to answer two questions: did something change, and when did it start? Use them before you log in.

- **CPU**: a flat line near the top for hours means the server is genuinely short of compute. Short spikes during deploys or cron jobs are normal.
- **RAM**: steady growth that never drops back often points to a memory leak or a cache that is allowed to grow without limit.
- **Network**: sudden jumps in outbound traffic are worth checking. On hourly billing, traffic is charged per GB used, so an unexpected spike also shows up on your balance. Monthly plans include a traffic allowance per location; the [VPS locations guide](https://cloudj.net/blog/vps-locations-guide) lists it for each country.

The console tells you what happened. To learn why, you need a shell. If you have not hardened the server yet, work through the [secure new VPS checklist](https://cloudj.net/blog/secure-new-vps-checklist) first so your monitoring is not hiding a login problem.

## Read the live picture with htop

`htop` is the friendliest real-time view of a Linux server. Install it and run it:

```bash
# Ubuntu / Debian
sudo apt update && sudo apt install -y htop sysstat

# AlmaLinux / Rocky Linux
sudo dnf install -y htop sysstat

htop
```

The header shows one bar per vCPU, memory and swap usage, and the load average for the last 1, 5 and 15 minutes. A useful rule: if the 15-minute load average stays above the number of vCPUs, processes are waiting for CPU time. Press `F6` to sort by `PERCENT_CPU` or `PERCENT_MEM`, and `F4` to filter by a process name such as `php-fpm` or `node`.

Two things to look for in the memory bar: how much is used by applications versus cache, and whether swap is in use. Linux uses free RAM as disk cache, so "almost full" is not automatically a problem. Active swap use with a slow application is.

## Spot pressure over time with vmstat

`htop` is a snapshot. `vmstat` prints a line every few seconds, which makes trends easier to see:

```bash
vmstat 5 10
```

That prints ten samples, five seconds apart. The columns that matter most:

| Column | Meaning | Worry when |
|---|---|---|
| `r` | processes waiting to run | consistently above your vCPU count |
| `si` / `so` | memory swapped in / out per second | regularly above zero |
| `wa` | CPU time waiting for disk I/O | high while the app feels slow |
| `st` | CPU time taken by the hypervisor | consistently high on a shared CPU plan |
| `id` | idle CPU | near zero for long periods |

A high `st` value on a shared ("Availability") plan means your vCPU is waiting for physical CPU time. If that pattern is steady and your workload is CPU-heavy, a general purpose or dedicated CPU plan is the honest fix; tuning code will not change it.

## Check disk I/O and space

Disk problems often look like CPU problems because processes stall while they wait. `iostat` comes from the `sysstat` package you installed above:

```bash
iostat -xz 5 3
```

Watch `%util` and `await` for your main disk. High utilization with rising wait times means the disk is the bottleneck. Then check space, because a full disk breaks databases and logs in confusing ways:

```bash
df -h
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20
```

Old logs, Docker images and database dumps are the usual suspects. `sudo journalctl --vacuum-size=200M` trims the systemd journal, and `docker system df` shows what Docker is holding.

## Watch network usage per interface

For a quick view of traffic per network interface, `sar` (also from `sysstat`) works well:

```bash
sar -n DEV 5 3
```

To see which connections are open and which processes own them:

```bash
sudo ss -tunap | head -40
```

If you suspect latency rather than bandwidth, the [ping and mtr testing guide](https://cloudj.net/blog/test-vps-latency-ping-mtr) explains how to measure the route between your users and the server.

## Add simple alerts without a monitoring stack

You do not need a full observability platform to get warned. A small shell script run by cron covers the most common failures: disk filling up and memory running out.

```bash
sudo tee /usr/local/bin/resource-check.sh > /dev/null <<'EOF'
#!/usr/bin/env bash
DISK_LIMIT=85
MEM_LIMIT=90
disk=$(df --output=pcent / | tail -1 | tr -dc '0-9')
mem=$(free | awk '/Mem:/ {printf "%d", ($3/$2)*100}')
if [ "$disk" -ge "$DISK_LIMIT" ] || [ "$mem" -ge "$MEM_LIMIT" ]; then
  logger -t resource-check "disk=${disk}% mem=${mem}%"
  curl -s -X POST -H 'Content-Type: application/json' \
    -d "{\"text\":\"$(hostname): disk ${disk}% mem ${mem}%\"}" \
    "$ALERT_WEBHOOK_URL" > /dev/null
fi
EOF
sudo chmod +x /usr/local/bin/resource-check.sh
```

Then schedule it every five minutes with `sudo crontab -e`:

```bash
ALERT_WEBHOOK_URL=https://your-chat-webhook-url
*/5 * * * * /usr/local/bin/resource-check.sh
```

Point the webhook at Slack, Discord, Telegram or any chat tool that accepts incoming webhooks. For long-term history, `sysstat` can also collect data in the background: enable it with `sudo systemctl enable --now sysstat`, then read past samples with `sar -u` or `sar -r`. When you grow beyond one or two servers, a dedicated tool such as Prometheus with node_exporter is worth the setup time.

## When to tune, resize or move

Monitoring is only useful if it leads to a decision. Use this order:

1. **Fix obvious waste first.** A runaway process, an unbounded cache or a missing database index can use more resources than your real traffic.
2. **Resize when the pattern is steady.** If CPU sits high or the server swaps every day under normal load, add capacity. Cloudj lets you resize CPU and RAM and grow the disk from the console; the [resize guide](https://cloudj.net/blog/resize-vps-cpu-ram-disk) covers the steps and what to check before you start.
3. **Change CPU type when steal time is the issue.** Shared vCPUs suit bursty work. Steady, CPU-heavy jobs belong on general purpose or dedicated cores.
4. **Move when the problem is distance.** If resources look fine but users still wait, the server may be too far from them. The guide on [choosing a VPS location by latency](https://cloudj.net/blog/choose-vps-location-latency) helps you decide.

Plans start at 1 vCPU and 1 GB RAM in most locations and go up to custom sizes, so you can usually grow in small steps instead of jumping to a much larger server. See current sizes on the [cloud servers page](https://cloudj.net/cloud-servers) and live prices on the [pricing page](https://cloudj.net/pricing).

## FAQ

### How often should I check my VPS metrics?

Glance at the console graphs after each deploy and once a week otherwise. Let alerts handle the rest so you are not watching graphs all day.

### Is high RAM usage always a problem?

No. Linux fills spare memory with disk cache and releases it when applications need it. Swap activity and slow responses are the real warning signs.

### What does steal time mean on a VPS?

It is CPU time your virtual machine wanted but had to wait for. Consistently high steal on a shared plan is a reason to consider dedicated CPU.

### Do I need to install an agent to see console metrics?

No. CPU, RAM and network graphs appear on the server page in the Cloudj console. Tools like `htop` and `sysstat` add detail inside the server.

## Keep an eye on it, then right-size

A few minutes with the console graphs, `htop`, `vmstat` and `iostat` will usually show whether you need to fix code, add resources or move closer to your users. When you are ready to resize or add a server, open the [Cloudj console](https://app.cloudj.net); it shows the exact price before you deploy.