Monitoring Your Server
Track CPU, memory, disk, and network usage - catch problems before your users do.
A VPS that’s out of disk space or pinned at 100% CPU doesn’t send you a polite email. You find out when your site goes down. Set up basic monitoring from day one.
Quick Status Check
SSH into your server and run these to get a snapshot:
# CPU and memory at a glance
top -bn1 | head -20
# Disk usage
df -h
# Memory
free -h
# Who's connected
w
CPU and Memory: htop
htop is the best quick tool for seeing what’s happening on your server in real time.
What to look for:
| Metric | Healthy | Problem |
|---|---|---|
| CPU usage | < 80% sustained | > 90% sustained - something is grinding |
| Memory | < 85% used | > 95% - OOM killer might start terminating processes |
| Load average | Below CPU core count | Above 2x core count - server is overloaded |
| Swap usage | Near 0 | High swap = not enough RAM |
Press F6 in htop to sort by CPU or memory. Press F9 to kill a runaway process.
Disk Usage
Running out of disk space breaks everything - databases crash, logs stop writing, websites 500.
# Overview of all partitions
df -h
# Find the biggest directories
du -sh /* 2>/dev/null | sort -rh | head -10
# Drill into a specific directory
du -sh /var/log/* | sort -rh | head -10
Common disk hogs:
| Location | Cause | Fix |
|---|---|---|
/var/log/ | Log files growing unchecked | Set up logrotate (see below) |
/tmp/ | Leftover session files | Clean with find /tmp -mtime +7 -delete |
/var/lib/mysql/ | Database bloat | Optimize tables, clean old data |
/home/*/mail/ | Large mailboxes | Ask users to archive old email |
| Docker images | Unused layers and containers | docker system prune -a |
Set Up Log Rotation
Most Linux distributions include logrotate by default. Verify it’s working:
cat /etc/logrotate.conf
ls /etc/logrotate.d/
If your application writes its own logs (e.g., to /var/www/app/logs/), add a config:
sudo nano /etc/logrotate.d/myapp
/var/www/app/logs/*.log {
daily
missingok
rotate 14
compress
notifempty
create 0640 www-data www-data
}
This rotates logs daily, compresses old ones, and keeps 14 days.
Network
# Current connections
ss -tunap
If you see hundreds of connections from a single IP, that might be a bot or an attack. Check your firewall rules.
Uptime and Load
uptime
Output example:
14:23:01 up 42 days, 3:15, 1 user, load average: 0.12, 0.08, 0.05
The three load average numbers represent the last 1, 5, and 15 minutes. On a 4-core server, a load average of 4.0 means all cores are fully busy. Anything consistently above your core count means requests are queuing.
Setting Up Alerts
Monitoring is useless if you’re not watching. Set up alerts so problems come to you.
Simple Disk Space Alert (Cron)
sudo crontab -e
Add this line:
# Check disk space every hour, email if over 85%
0 * * * * df -h / | awk 'NR==2{gsub(/%/,""); if($5>85) print "Disk at "$5"% on '$(hostname)'";}' | mail -s "Disk Alert" you@yourdomain.com
Monitoring Services
For a proper monitoring setup with dashboards and alerting:
- Uptime Kuma - self-hosted uptime monitor with notifications (Slack, email, Telegram). Simple to set up in Docker
- Netdata - real-time server metrics with a web dashboard. Install with one command:
bash <(curl -Ss https://my-netdata.io/kickstart.sh)
- Prometheus + Grafana - industry-standard stack for multi-server monitoring. More complex to set up, but extremely powerful
htop checks are enough. Scale up to Prometheus when you have multiple servers.What to Do Next
- First Boot: Initial Server Setup - make sure your server is secured before exposing it
- Choosing an Operating System - different distributions have different default monitoring tools
Last updated 05 Apr 2026, 00:00 +0200.