VPS Monitoring 2026: Netdata, Uptime Kuma & Prometheus Setup Guide

Three complementary stacks: Netdata for depth, Uptime Kuma for external checks, Prometheus + Grafana for scale

1. Why You Must Monitor Your VPS Before It Fails

If you host a website, an app, a Minecraft server, or a Nextcloud instance on a VPS, you have probably already discovered an outage from a user DM or a customer email. By the time you know, the site has been down for minutes or hours. Monitoring flips that equation: you are the first to know, every time.

Good monitoring does three jobs at once:

• Tells you that something is broken before your visitors do (external uptime checks).
• Tells you why it is broken - was it a CPU spike? an out-of-memory kill? a disk that silently filled up? (in-system metrics).
• Tells you it is about to break - slow trends (rising RAM usage, shrinking free disk, climbing latency) you can act on during business hours instead of at 3 AM.

The 2026 monitoring landscape has settled on three excellent open-source tools, each designed for a different job. Stacking all three gives you enterprise-grade observability on a budget VPS. Stacking them incorrectly (running Uptime Kuma on the server it watches, for example) gives you a false sense of security.

2. Eight Metrics That Actually Matter

You do not need 200 charts on your wall. Eight metrics cover 95% of real production incidents on a VPS.

Track these eight and you will catch nearly every real-world incident

Three of these deserve special emphasis because they cause silent failures that show up weeks after the root cause:

• Disk space. Log rotation fails, databases stop committing, backups silently crash - all from a root filesystem that quietly hits 100%. Alert at 80% so you have time to clean up.
• Swap usage. A VPS that starts swapping under load will look "up" from ping but feel glacial to users - exactly the kind of degradation that goes unnoticed until complaints pour in.
• SSL certificate days remaining. Cert expiry is the most avoidable outage in existence. Alert 14 days out, not 1 day out.

3. Which Tool to Choose: A Side-by-Side Comparison

Each of the three tools in this guide solves a different problem. Picking the wrong one is the most common mistake newcomers make.

Start simple; add complexity only when the simple setup stops working

Here is the decision tree in one paragraph:

1. Always install Netdata on every VPS you own. It takes 30 seconds, uses almost no RAM, and gives you instant visibility.
2. Always run an external uptime probe from a second VPS (Uptime Kuma) or a third-party service (UptimeRobot free tier). Internal metrics cannot tell you that a network outage has taken your whole data center offline.
3. Only when you hit 10+ servers, or need long-term retention, or want custom Grafana dashboards, add Prometheus + Grafana. Do not start here.

4. Part 1 - Install and Configure Netdata in 5 Minutes

Netdata is a single binary that installs with one command, auto-detects every service on your VPS (Nginx, MySQL, Redis, Docker, Postgres, PHP-FPM), and starts streaming a beautiful dashboard to port 19999 immediately.

4.1 Installation

# On any Ubuntu 22.04 / 24.04 or Debian 12 VPS:
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sudo sh /tmp/netdata-kickstart.sh --non-interactive

# Verify:
sudo systemctl status netdata
# You should see: active (running)

Once running, visit http://YOUR-VPS-IP:19999 and you will see a full dashboard like this:

Default Netdata dashboard after a fresh install - zero configuration needed

4.2 Lock It Down (do not expose 19999 to the internet)

By default Netdata listens on all interfaces. Restrict it to localhost and access it through an SSH tunnel or an Nginx reverse proxy with a password.

sudo tee /etc/netdata/netdata.conf 

4.3 Configure a Real Alert

Out of the box Netdata ships with dozens of sensible alerts, but you must tell it where to send them. Telegram is the most popular choice for solo operators because it works reliably on your phone without a paid plan.

# Edit the Telegram alert config
sudo tee /etc/netdata/health_alarm_notify.conf > /dev/null 

5. Part 2 - Deploy Uptime Kuma on a Second VPS

This is the single most important sentence in this entire guide: never run Uptime Kuma on the VPS it is monitoring. If your production VPS goes down, the Kuma running on it will also go down, and you will receive zero alerts.

The fix is cheap: buy a second VPS in a different data center. If your production site is on LuckVM Hong Kong, put Kuma on LuckVM Los Angeles ($8.80/month) or LuckVM Singapore ($11/month). Total cost is less than one coffee per week.

Six steps to a fully operational external uptime monitor

5.1 Install Docker

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
# Log out and back in for the group change to apply

5.2 Deploy Uptime Kuma with Docker Compose

mkdir -p ~/uptime-kuma && cd ~/uptime-kuma
tee docker-compose.yml 

5.3 Put It Behind Nginx with SSL

sudo apt install -y nginx certbot python3-certbot-nginx
sudo tee /etc/nginx/sites-available/kuma 

Now open https://status.yourdomain.com, create your admin user, and add your first monitor. For a typical web app, create these five monitors:

• HTTP(s) Keyword check against your homepage, expecting a keyword like "Welcome" - this catches the dreaded "white page of death" when your app returns a blank 200.
• TCP port check on port 22 (SSH) and 3306 (MySQL, from an internal network) to detect service crashes that Nginx might mask.
• Ping for raw reachability; alerts you before the HTTP stack is even up.
• DNS check if you run your own resolver, otherwise a DNS lookup to a known good target to detect upstream DNS outages.
• SSL certificate expiry check - Kuma can warn you 14, 7, and 1 day before any cert on any monitored domain expires.

6. Part 3 - Prometheus + Grafana for Multi-Server Fleets

Once you run more than about 10 servers, Netdata's per-node dashboards become inconvenient, and you will want a single pane of glass. That is what the Prometheus + Grafana + Alertmanager stack is for.

The classic open-source monitoring stack: scrape, store, alert, visualize

6.1 Deploy the Full Stack with Docker Compose

mkdir -p ~/monitoring/{prometheus,grafana,alertmanager} && cd ~/monitoring

# Prometheus config
tee prometheus/prometheus.yml  85
        for: 10m
        labels: { severity: warning }
        annotations:
          summary: "CPU above 85% for 10 min on {{ $labels.instance }}"
      - alert: DiskFilling
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) 

6.2 Install node_exporter on Every Server You Want to Monitor

# Run on each production VPS (not on the monitoring VPS):
wget https://github.com/prometheus/node_exporter/releases/latest/download/node_exporter-1.8.2.linux-amd64.tar.gz
tar xzf node_exporter-*.linux-amd64.tar.gz
sudo mv node_exporter-*.linux-amd64/node_exporter /usr/local/bin/

sudo tee /etc/systemd/system/node_exporter.service 

After 2-3 minutes, open http://localhost:3000 (via SSH tunnel to the monitoring VPS), log into Grafana with admin / the password you set, add Prometheus as a data source at http://prometheus:9090, and import dashboard 1860 (Node Exporter Full) from the public dashboard library - you will immediately have one of the best open-source infrastructure dashboards ever built.

7. Alerting That Wakes You Up When It Matters

Alert routing is the part of monitoring teams get wrong most often. The cardinal rule is never page a human for something they cannot fix. If CPU is at 90% for 10 minutes but requests are still fast and users are not complaining, send an email or a Slack message, not a 3 AM push notification.

Recommended channel routing for solo operators and small teams:

8. Five Common Monitoring Mistakes to Avoid

1. Monitoring the server from itself. External uptime probes must live on a different server in a different network. Same box = same failure domain.
2. Over-alerting. Every alert must have a defined action. "Disk at 80%" should not be critical at 2 AM; it should be a morning email.
3. No retention policy. Netdata stores detailed metrics for a few days by default. For trend analysis you need weeks or months - configure retention or route to Prometheus.
4. Forgetting to test alerts. Once a month, deliberately stop Nginx on a staging box and confirm you actually get the alert. Alerts that were never tested do not work.
5. Ignoring egress costs. Prometheus pulls metrics every 15s; across 20 servers this is trivial. Shipping logs or traces can burn bandwidth quickly on metered plans.

9. Which LuckVM Plan for Monitoring?

Monitoring workloads are light on RAM but benefit from a stable, well-connected VPS because they need to reach all your production servers reliably.

Prices shown are as of October 2026 on the LuckVM website; check the pricing page for current offers. If most of your production is in Asia (Hong Kong / Tokyo / Singapore), locate your monitoring VPS in Los Angeles so that a regional fiber cut does not take out both prod and monitoring at once.

10. Frequently Asked Questions