VPS Monitoring: Keep Your Server Running 24/7

June 2026 · 6 min read

A server crashing at 3 AM with no one knowing is every VPS owner's nightmare. This article brings together real monitoring tools and setup methods that work without requiring any payment.

What You Should Monitor

• CPU Usage — If consistently above 90%, something is wrong
• RAM — When full, the system starts swapping and performance tanks
• Disk Space — When full, databases can't write, and your site goes down
• Uptime / Downtime — Is your web service responding?
• Load Average — Average system load over 1, 5, and 15 minutes

Basic Checks via Command Line

# View CPU, RAM, Load in real-time
top
htop   # prettier, requires separate install

# View Disk Space
df -h

# View RAM
free -h

# View Load Average
uptime

# View processes consuming the most resources
ps aux --sort=-%cpu | head -10

Set Up Email Alerts When Disk is Running Low

Create a script at /usr/local/bin/disk-check.sh:

#!/bin/bash
THRESHOLD=85
USAGE=$(df / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ "$USAGE" -gt "$THRESHOLD" ]; then
  echo "Disk usage is ${USAGE}% on $(hostname)" | \
    mail -s "ALERT: Disk Space Low" [email protected]
fi

Add to crontab to run every hour:

0 * * * * /usr/local/bin/disk-check.sh

Uptime Kuma: Monitoring You Can Run on Your Own VPS

Uptime Kuma is an open-source uptime monitor that you can install on your own VPS. It has a beautiful UI and sends alerts via Line, Telegram, Email, Slack, and more.

Install with Docker:

docker run -d --restart=always -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma louislam/uptime-kuma:1

Open it at http://your-server:3001 and configure monitors for your websites

Netdata: Real-Time Monitoring Dashboard

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Access port 19999 to see a real-time dashboard with metrics updated every 1 second

Important: Exposing port 19999 directly to the internet is a security risk. Block it with a firewall and use SSH tunneling instead.

Warning Signs You Shouldn't Ignore

• Load average consistently higher than your number of CPU cores
• Memory swap usage greater than 0 continuously
• Disk more than 80% full with no cleanup plan
• Logs filled with "connection refused" or "too many open files"

Setting Up Alerts Through Multiple Channels

Beyond Uptime Kuma, you can set up alerts for critical metrics with simple scripts:

#!/bin/bash
# /usr/local/bin/health-check.sh
HOSTNAME=$(hostname)
ALERT_EMAIL="[email protected]"

# Check Disk
DISK=$(df / | tail -1 | awk '{print $5}' | tr -d '%')
[ "$DISK" -gt 85 ] && echo "Disk ${DISK}% on $HOSTNAME" | \
  mail -s "ALERT: Disk Full" $ALERT_EMAIL

# Check RAM
MEM_FREE=$(free | awk '/^Mem:/{printf "%.0f", $4/$2*100}')
[ "$MEM_FREE" -lt 10 ] && echo "RAM only ${MEM_FREE}% free on $HOSTNAME" | \
  mail -s "ALERT: Low Memory" $ALERT_EMAIL

# Check Load
LOAD=$(uptime | awk -F'load average:' '{print $2}' | cut -d, -f1 | xargs)
CPU=$(nproc)
LOAD_INT=$(echo "$LOAD * 10" | bc | cut -d. -f1)
[ "$LOAD_INT" -gt "$((CPU * 10))" ] && echo "High load $LOAD on $HOSTNAME" | \
  mail -s "ALERT: High CPU Load" $ALERT_EMAIL

chmod +x /usr/local/bin/health-check.sh
# Add to crontab to run every 10 minutes
*/10 * * * * /usr/local/bin/health-check.sh

Check Open Ports

Verify which ports are listening to find services that shouldn't be exposed:

# View all listening ports
ss -tlnp
# or
netstat -tlnp

# View only ports accessible from outside (not just 127.0.0.1)
ss -tlnp | grep -v "127.0.0.1\|::1"

View Logs in Real-Time

# View system logs in real-time
journalctl -f

# View nginx access and error logs together
tail -f /var/log/nginx/access.log /var/log/nginx/error.log

# View only errors
journalctl -p err..alert -f

# View logs for a specific service
journalctl -u nginx -f

Verify Your Monitoring is Working Correctly

After setting up agents and exporters, verify that metrics are being collected and alerts actually fire — monitoring that's "installed but never tested" is unreliable:

# 1. Check if node_exporter is responding
curl -s localhost:9100/metrics | head -20

# 2. Check if Prometheus scrape target is healthy (state should be up)
curl -s localhost:9090/api/v1/targets | grep -o '"health":"[a-z]*"'

# 3. Test alert by intentionally using CPU and seeing if the rule fires
stress-ng --cpu 4 --timeout 60s   # apt install stress-ng

# 4. Verify disk/memory metrics match reality
free -m && df -h /

Common Issues & Troubleshooting

htop not found after fresh server install

apt install htop -y   # Ubuntu/Debian
yum install htop -y   # CentOS/AlmaLinux

Cannot access Uptime Kuma from browser

# Check if container is running
docker ps | grep uptime-kuma

# View logs
docker logs uptime-kuma --tail 50

# Verify port 3001 is open
ufw allow 3001/tcp

Disk full but df -h shows available space

This usually means inode exhaustion, not disk space:

# Check inode usage
df -i /
# If Use% is near 100%, inodes are exhausted

# Find directories with the most files
find / -xdev -type f | cut -d/ -f2 | sort | uniq -c | sort -rn | head

High load average but CPU is not at 100%

Load average includes I/O wait. If CPU is low but load is high, disk I/O is the problem:

iostat -x 1 5   # View disk I/O
# If %util is near 100%, disk is saturated

iotop   # See which processes are using disk

Frequently Asked Questions

How do I monitor multiple VPS at the same time?

Install Uptime Kuma on a single machine, then add monitor entries for each VPS's URL or IP address. Alternatively, use Netdata Cloud, which aggregates dashboards from multiple servers for free up to 5 nodes.

Does Netdata consume a lot of resources?

Netdata typically uses 50–200 MB of RAM and 1–3% CPU under normal conditions. On a 1 GB VPS it may be heavy. We recommend running it on 2 GB+ VPS or using script-based alerts and Uptime Kuma instead, which are much lighter.

What should I monitor at minimum?

Four things are essential: (1) HTTP uptime check every 1–5 minutes (2) Disk usage alert when exceeding 80% (3) SSL certificate expiry alert 14 days before expiration (4) Memory/swap alert when free is less than 10%. All four can be set up free with Uptime Kuma or via script and cron.

What's the difference between Load Average and CPU Usage?

CPU Usage is the percentage of time the CPU is actively working. Load Average is the number of processes waiting for CPU or disk I/O, averaged over 1, 5, or 15 minutes. A healthy load average should stay below your number of CPU cores — if load is 2 on a 1-core server, the server is under heavy stress.

Summary

Good monitoring doesn't have to be expensive. Uptime Kuma on your own VPS works excellently. The key is setting up alerts before problems occur, not after your site goes down. Start with disk and uptime alerts, then expand as needed.