How to Monitor a Linux VPS with Netdata

A VPS with no monitoring installed only tells you about a problem after it has already become one — the process that has been leaking memory for six hours, the disk that filled up overnight, the CPU spike from a runaway cron job three days ago. Netdata closes that gap by collecting and charting server metrics every second, live, from the moment it starts running, with no separate database to configure and no dashboard to build from scratch. This guide installs it on a fresh Linux VPS and walks through the parts that matter once it's running: the local dashboard, health alarms, and locking the whole thing down so it isn't exposed to the internet.

What Netdata Actually Collects

Netdata is an open-source monitoring agent that runs directly on the machine it watches, pulling metrics from the kernel and running processes at one-second resolution rather than the 30- or 60-second intervals common to older monitoring tools. Out of the box it tracks CPU usage per core, memory and swap, disk I/O and space, network interfaces, running processes, and — on a VPS running common services — plugin-based collectors for things like nginx, MySQL, and Docker containers when it detects them installed. Everything renders as an interactive, auto-updating chart in a browser, with no manual dashboard-building step.

The design goal is different from a tool like Prometheus paired with Grafana, which is powerful but requires you to stand up a separate time-series database and build dashboards before it tells you anything. Netdata is meant to be useful within a minute of installation: install it, open the dashboard, and the charts are already populated.

Installing Netdata with the Kickstart Script

The supported installation method on a Linux VPS is Netdata's kickstart script, which detects your distribution and package manager and installs the agent as a native package where possible, falling back to a static build when it isn't. Download and run it:

1curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh
2sh /tmp/netdata-kickstart.sh

The script explains each step as it runs — it adds Netdata's repository (or downloads a static binary for unsupported distributions), installs the agent, and starts it as a systemd service. It also prompts you partway through about whether to connect the node to Netdata Cloud; you can accept, decline, or do it later, covered below. The full source of the installer and every supported install path is documented in the Netdata GitHub repository, which is the project's canonical home for release notes and issue tracking if something about a specific distribution needs troubleshooting.

Once the script finishes, confirm the service is actually running:

1sudo systemctl status netdata

A systemd active (running) status means the agent has already started collecting metrics — there is no separate "start monitoring" step.

Accessing the Local Dashboard

Netdata's dashboard runs on port 19999 by default and needs no setup to view. Point a browser at:

1http://<your-vps-ip>:19999

and the dashboard loads immediately, already populated with charts covering the seconds and minutes since the agent started. Scroll down and each subsystem — CPU, memory, disks, network interfaces, and any detected application collectors — gets its own row of charts you can zoom, pan, and hover over for exact per-second values. There's no query language to learn for the default view; the dashboard is generated automatically from whatever the agent is collecting on that host.

This is also the point at which the single biggest gotcha with a stock Netdata install shows up: port 19999 is open and unauthenticated by default. If your VPS has no firewall rule blocking it, anyone who knows (or scans for) the IP and port can view your server's metrics. The Security section below covers closing that off.

Setting Up Health Alarms

Netdata ships with a substantial set of built-in health checks — disk space thresholds, high CPU sustained over time, memory pressure, and more — configured through files under /etc/netdata/health.d/. These alarms are active from install with sensible defaults; you don't have to write rules from scratch to get baseline coverage.

To route alarm notifications somewhere you'll actually see them (email, Slack, or another channel), the configuration lives in /etc/netdata/health_alarm_notify.conf. Copy the file into place from the stock config, edit the section for your chosen notification method, and reload:

1sudo cp /etc/netdata/health_alarm_notify.conf /etc/netdata/health_alarm_notify.conf.bak
2sudo nano /etc/netdata/health_alarm_notify.conf
3sudo systemctl restart netdata

Individual alarm thresholds — say, tightening the disk-space warning if your VPS has a small volume — live in the .conf files under health.d/, one per subsystem (disk.conf, ram.conf, and so on). Edit the relevant file, restart the service, and the new threshold takes effect on the next check cycle.

Connecting to Netdata Cloud

Running the agent locally is enough for a single VPS, but if you're watching several servers, Netdata Cloud gives you one dashboard that aggregates every claimed node instead of bookmarking a separate :19999 URL per server. Claiming a node links the locally running agent to a Cloud "space" using a claim token generated when you sign up — the kickstart installer offers to do this during install, or you can run the claiming step afterward from the Cloud UI's "connect node" flow, which generates the exact command for your account.

Claiming is optional. The local dashboard works fully on its own with no account and no internet dependency — Cloud is purely a convenience layer for viewing multiple nodes together and does not change what the local agent collects.

Securing the Dashboard

Because port 19999 is open and unauthenticated by default, the first real hardening step on a public VPS is deciding who can reach it. Two solid options:

Restrict by firewall. If you don't need remote dashboard access at all, block the port from the outside and view it over an SSH tunnel instead:

1sudo ufw deny 19999
2ssh -L 19999:localhost:19999 user@your-vps-ip

With the tunnel running, http://localhost:19999 on your own machine reaches the remote dashboard without the port ever being exposed publicly. UFW is the standard firewall front-end on Ubuntu VPS images and handles this in one line.

Put it behind a reverse proxy with authentication. If you want browser access without a tunnel, proxy port 19999 through nginx on port 443 and add HTTP basic auth in front of it, so the dashboard is reachable over HTTPS with a login prompt rather than sitting open on a raw port.

Either approach is preferable to leaving 19999 open to the world — server metrics reveal what's running, how busy it is, and often enough about your traffic patterns that they shouldn't be public by default.

Who This Setup Is Best For

Good fit:

• A single VPS or a small handful of servers where you want immediate visibility with minimal setup
• Diagnosing a specific ongoing issue — a slow app, a mystery CPU spike — where per-second granularity actually matters
• Anyone who wants working alarms without hand-writing threshold rules first

Not the best fit:

• Large fleets needing long-term metric retention and complex custom dashboards, where a dedicated Prometheus/Grafana stack is more purpose-built
• Environments with strict policies against running additional always-on agents with kernel-level access

Pros and Cons

Pros

• Live, per-second metrics with no manual dashboard-building
• Built-in health alarms active immediately after install
• Runs entirely locally by default — no external dependency required

Cons

• Dashboard is unauthenticated on its default port and needs manual hardening
• Best suited to per-node visibility; multi-node aggregation depends on the optional Cloud layer

Final Verdict

For a single Linux VPS, Netdata is one of the fastest paths from "no monitoring at all" to a live, per-second view of exactly what the server is doing — the kickstart script, a systemd service, and a populated dashboard, in a few minutes. The trade-off is that the convenience comes with an open port you have to remember to lock down; do that first, set up alarm notifications second, and the rest of the setup takes care of itself.

References

• UFW — Uncomplicated Firewall (Ubuntu community documentation)
• nginx reverse proxy module documentation