Most people find out their VPS has a problem the same way: a customer emails, or the site just stops loading. By then you're already troubleshooting under pressure, digging through logs to figure out what happened an hour ago. Netdata flips that around — it's a free, open-source monitoring agent that shows you CPU, memory, disk, and network activity as it happens, per-second, and can ping you before a slow leak turns into an outage. Here's how to get it running on a SkyServer VPS properly, including the part most tutorials skip: locking the dashboard down so a stranger can't see your server's vitals.
Why "It Was Fine Yesterday" Isn't Good Enough
Tools like top and htop are fine for a quick look, but they only show you right now. If MySQL spiked to 100% CPU for six minutes at 3 a.m. and then settled down, you'll never see it in top — by the time you SSH in, the evidence is gone. Log files help after the fact, but they don't tell you disk I/O was climbing for three days before it finally choked. What you actually want is a running history: something recording every resource on the box, all the time, so when something goes wrong you can look back and see exactly when it started and what else happened at the same moment.
What Netdata Actually Gives You
Netdata is a lightweight agent (written in C, minimal overhead) that collects thousands of metrics per second — CPU per core, RAM and swap, disk I/O and space, network throughput, running processes, MySQL/Nginx/Apache stats if those services are present — and serves it all as a live dashboard in your browser. No separate database to manage, no complex setup for the basics. It also ships with sane default alert thresholds (disk filling up, RAM exhausted, load average too high) that you can tune or extend.
It's not a replacement for something like Zabbix or Prometheus/Grafana if you're managing a fleet of servers with long-term trend analysis across years of data. But for a single VPS or a handful of them, it's the fastest path from "nothing" to "I'll know within a minute if something's wrong."
Installing Netdata
On any Ubuntu, Debian, AlmaLinux, or Rocky VPS, the official one-line installer handles everything — dependencies, service setup, and auto-start on boot:
wget -O /tmp/netdata-kickstart.sh https://get.netdata.cloud/kickstart.sh
sh /tmp/netdata-kickstart.shIt'll ask a couple of questions during install (whether to auto-update, whether to connect to Netdata Cloud for remote viewing). If you just want a local dashboard, decline the Cloud connection for now — you can always add it later. Once it finishes, confirm the service is running:
systemctl status netdataBy default Netdata listens on port 19999. Do not open that port to the world yet — that's the mistake almost everyone makes on their first install.
Locking Down the Dashboard
An open Netdata dashboard leaks a lot: your OS version, running processes, IPs your server talks to, even application names. Treat it like phpMyAdmin or WHM — never expose it directly on a public port. Two solid options:
- Firewall it to your IP only. With UFW:
ufw allow from YOUR.HOME.IP.ADDR to any port 19999, then make sure the default deny is active for that port from everywhere else. - Put it behind Nginx with basic auth, so you can reach it over HTTPS with a password instead of juggling firewall rules whenever your IP changes. A minimal reverse proxy block:
location /netdata/ {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.netdata_htpasswd;
proxy_pass http://127.0.0.1:19999/;
proxy_set_header Host $host;
}Generate the password file with htpasswd -c /etc/nginx/.netdata_htpasswd youruser, reload Nginx, and you've got a password-protected dashboard over your existing SSL certificate instead of a bare, unencrypted port.
Setting Up Alerts That Actually Reach You
The dashboard is only useful if you're looking at it. The real value is alerting — Netdata's health engine watches every metric against threshold rules and can notify you the moment something crosses the line. Default alerts already cover the basics (disk >90% full, load average too high, RAM pressure), but you'll want to wire up a notification channel so they actually reach you.
The config lives in /etc/netdata/health_alarm_notify.conf. It supports email out of the box (uses your server's mail setup) plus Slack, Telegram, Discord, and a dozen other services via webhook. For a quick email hookup:
cd /etc/netdata
./edit-config health_alarm_notify.conf
# set: SEND_EMAIL="YES"
# set: DEFAULT_RECIPIENT_EMAIL="you@yourdomain.com"Restart the service after editing (systemctl restart netdata) and trigger a test alert to confirm delivery:
/usr/libexec/netdata/plugins.d/alarm-notify.sh testIf you'd rather get pinged on your phone instantly, Telegram is the easiest of the chat integrations to set up — create a bot with @BotFather, grab the token and your chat ID, drop both into the same config file, and you'll get alerts as fast as email arrives, sometimes faster.
What to Actually Watch
Once it's running, don't try to monitor everything at once. Start with the metrics that predict downtime, not just describe it:
| Metric | Why it matters | Typical warning sign |
|---|---|---|
| Disk space (per partition) | Full disk crashes MySQL and stops writes silently | Sustained upward trend, not just a spike |
| Load average vs core count | Load consistently above core count means requests are queuing | Load > 2x cores for more than a few minutes |
| RAM + swap usage | Heavy swap use means the box is thrashing, not just "using memory" | Swap usage climbing steadily under normal traffic |
| Disk I/O wait (iowait) | High iowait with normal CPU usually means a slow disk or noisy neighbor | iowait consistently above 10-15% |
| MySQL connections | Approaching max_connections before the error actually hits | Steady climb toward your configured max |
Once you've watched the dashboard for a week or two during normal traffic, you'll know what "normal" looks like for your specific workload — and any alert that fires after that is worth taking seriously.
Prevention: Keep the Signal Useful
Alert fatigue kills monitoring faster than anything else. If Netdata's default thresholds are too sensitive for your traffic pattern and you're getting paged for nothing, you'll start ignoring every alert — including the real one. Tune the noisy rules in /etc/netdata/health.d/ rather than disabling alerting altogether. Also budget a few minutes a month to check that notifications are still arriving; mail servers change SMTP settings, Telegram bots get revoked, and a monitoring system that fails silently is worse than none at all, because you'll assume you'd have been told.
Frequently Asked Questions
Does Netdata slow down my VPS?
Its footprint is small — typically under 5% of a single core and a modest chunk of RAM for the metrics buffer, even on a low-end VPS. If you're on a 1 GB RAM plan, keep an eye on memory usage after install, but for anything 2 GB and up it's rarely noticeable.
Can I monitor multiple VPS instances from one place?
Yes. You can either connect each install to Netdata Cloud (free tier covers a generous number of nodes) for a single unified view, or set up a parent-child streaming configuration where one Netdata instance collects data from several servers. Start with one server first, then expand once you're comfortable with the config files.
Is Netdata a replacement for cPanel/WHM's built-in resource stats?
No, they serve different purposes. WHM's resource monitor shows account-level limits set by CloudLinux (LVE), useful on shared or reseller hosting. Netdata monitors the whole server at the OS level with far more detail and real alerting. On a VPS you control directly, Netdata is the better tool; the two aren't mutually exclusive if you're running cPanel on your VPS.
What happens to historical data if the server reboots?
By default, Netdata keeps a rolling window of recent metrics in memory and on disk (configurable retention, typically a few hours to a couple of days depending on RAM). For long-term history beyond that, connect it to Netdata Cloud or export metrics to a time-series database like Prometheus.
I already have fail2ban and a firewall — do I still need this?
Different job. Fail2ban and your firewall stop unwanted access; Netdata tells you when your own resources are running out or behaving oddly, which security tools won't catch. A brute-force attempt won't show up in fail2ban logs until it's blocked, but a resulting CPU spike will show up in Netdata immediately — the two complement each other rather than overlap.
