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 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 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 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:
# Ubuntu / Debian
sudo apt update && sudo apt install -y htop sysstat
# AlmaLinux / Rocky Linux
sudo dnf install -y htop sysstat
htopThe 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:
vmstat 5 10That 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:
iostat -xz 5 3Watch %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:
df -h
sudo du -xh / --max-depth=2 2>/dev/null | sort -h | tail -20Old 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:
sar -n DEV 5 3To see which connections are open and which processes own them:
sudo ss -tunap | head -40If you suspect latency rather than bandwidth, the ping and mtr testing guide 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.
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.shThen schedule it every five minutes with sudo crontab -e:
ALERT_WEBHOOK_URL=https://your-chat-webhook-url
*/5 * * * * /usr/local/bin/resource-check.shPoint 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:
- Fix obvious waste first. A runaway process, an unbounded cache or a missing database index can use more resources than your real traffic.
- 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 covers the steps and what to check before you start.
- 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.
- 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 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 and live prices on the pricing page.
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; it shows the exact price before you deploy.