VPS Monitoring Setup: Catch Problems Before the Site Goes Down

Most VPS owners find out something's wrong when a customer emails to say the site is down - or worse, when Google Search Console flags it first. By then the server's already been struggling for hours. A little monitoring set up in advance turns that into a Slack ping at 40% disk usage instead of a 2 AM outage at 100%.

Why "It Was Fine Yesterday" Isn't Good Enough

We've covered plenty of specific VPS fires in other guides - the OOM killer eating your MySQL process, a disk that quietly filled up, or a server that's suddenly pegged at 100% CPU. Every one of those posts starts the same way: something already broke, and now you're digging through logs to figure out why. Monitoring flips the order - you see the trend line climbing days before it becomes an incident, and you fix it on your schedule instead of a customer's.

You don't need an enterprise observability stack for one or two VPS instances. You need three things: a live dashboard, a way to get alerted without staring at it, and a five-minute-a-day habit of actually looking.

What to Actually Watch

• CPU load average - sustained above your core count for more than a few minutes, not just a momentary spike.
• Memory + swap usage - swap climbing steadily is an early warning the OOM killer is coming.
• Disk space - both the root partition and inode count; a full disk breaks MySQL writes and mail delivery instantly.
• Disk I/O wait - high iowait with normal CPU usually means a slow or overloaded disk, common on budget VPS plans.
• Open connections / process count - a runaway cron job or a bot attack shows up here first.

Option 1: Netdata - a Real Dashboard in About Five Minutes

Netdata is free, open-source, and gives you second-by-second graphs for all of the above without a config file marathon. On Ubuntu, Debian, AlmaLinux, or Rocky, the one-line installer handles everything:

wget -qO- https://get.netdata.cloud/kickstart.sh | sh

By default it binds to port 19999 on localhost only, which is the safe default - don't expose it to the public internet without a password in front of it. Two ways to view it securely:

• SSH tunnel (quick, no extra config): ssh -L 19999:127.0.0.1:19999 user@your-vps-ip, then open http://localhost:19999 in your local browser.
• Nginx reverse proxy with basic auth if you want to check it from your phone without an SSH client. We've covered the reverse proxy side of this in our Nginx reverse proxy guide - the same htpasswd approach applies here.

Turn On Alerts, Not Just Graphs

A dashboard nobody watches is decoration. Netdata ships with sane default alert thresholds (disk >90%, load average high, RAM pressure) but you still need to tell it where to send them. Edit the health alarm notification config:

sudo nano /etc/netdata/health_alarm_notify.conf

Set SEND_EMAIL="YES" and your DEFAULT_RECIPIENT_EMAIL, or configure the Slack/Discord/Telegram webhook block further down the same file - all three are supported out of the box. Restart the service to apply it:

sudo systemctl restart netdata

Trigger a test alert to confirm delivery before you trust it:

sudo /usr/libexec/netdata/plugins.d/alarm-notify.sh test

Option 2: No-Install Command-Line Checks

If you'd rather not run an extra daemon on a very small VPS (say, 1 GB RAM), these built-in commands cover the essentials in a 30-second SSH session:

Put the first four in a one-line cron job that emails you a daily snapshot if you want the poor man's version of alerting without installing anything new.

Option 3: Watch It From the Outside Too

Server-side monitoring won't tell you if your VPS is up but unreachable - a firewall misconfiguration, a dead Nginx process, or an upstream network issue can take the site down while every internal metric looks normal. Pair Netdata with a free external uptime checker (UptimeRobot, Better Uptime, or similar) that pings your site every few minutes from outside your network and texts or emails you the moment it stops responding. It's the only way to catch the case where the server itself thinks everything's fine.

Common Problems After Setup

Dashboard says "connection refused" over the SSH tunnel

Almost always the local port is already in use, or Netdata isn't actually running. Check with sudo systemctl status netdata and confirm nothing else is bound to 19999 with sudo ss -tlnp | grep 19999.

Netdata itself is using noticeable CPU on a 1-2 GB VPS

Its default collection interval is 1 second, which is fine on most servers but adds up on the smallest plans. Raise the interval in /etc/netdata/netdata.conf under the [global] section:

[global]
    update every = 5

Five-second granularity is still plenty to catch a trend before it becomes an outage.

Test alert works, but real alerts never arrive

Check whether outbound mail is actually leaving the server - if you're on a VPS (not shared cPanel hosting), this is often the same port 25 block that stops other outgoing mail. Point Netdata's email config at an SMTP relay on port 587 instead of relying on the server's local mail transport, or switch the alert channel to Slack/Telegram, which doesn't touch SMTP at all.

Prevention: Make It a Habit, Not a One-Time Setup

• Check the dashboard for thirty seconds each morning - trends are more useful than snapshots.
• Set alert thresholds a little below the real danger point (80% disk, not 95%) so you get days of warning, not minutes.
• Re-test your alert channel every time you change hosting providers, SMTP settings, or webhook URLs - a silently broken alert is worse than no alert, because you'll assume it's working.
• Review Netdata's default thresholds against your actual server size once a quarter; a 4 GB RAM VPS and a 32 GB one shouldn't share the same alarm limits.

None of this replaces backups, firewalls, or the other hardening steps we've covered elsewhere - monitoring just makes sure you're the first to know when something needs attention, instead of the last.