Learning Center

Monitor Disk, CPU, and Memory on a VPS With Netdata

Set up a real-time monitoring dashboard on your VPS so you can see resource pressure early instead of guessing after something breaks.

NetdataMonitoringVPS ops

What you learn

How to install Netdata, secure access to the dashboard, and use it to understand CPU spikes, memory pressure, and disk growth.

Best for

Single-server apps, small Docker stacks, and self-hosters who want more visibility without building a full observability platform first.

Risk to watch

An open monitoring dashboard can leak a surprising amount of server information. Keep Netdata private or protected.

Before you begin

An Ubuntu or Debian-based VPS with sudo access.
A plan to keep the dashboard private, such as firewall restrictions, Tailscale, or a reverse proxy with authentication.
A willingness to spend a few minutes learning what the charts actually mean.

Netdata is one of the quickest ways to get useful visibility on a small VPS. It is not just a pretty graph page. It helps you answer practical questions like: Is the disk filling up steadily or suddenly? Is memory pressure constant or only during deploys? Is CPU pinned by one process or by load across the whole box?

Expected outcome: You will have a working dashboard that shows live CPU, RAM, swap, load, network, disk usage, and per-process behavior, plus a safer access pattern than exposing it publicly.

Step 1: Install Netdata on the VPS

The Netdata project provides a one-line installer for common Linux systems. Start by updating packages:

sudo apt update && sudo apt upgrade -y
sudo apt install -y curl

Then install Netdata:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

When the installer finishes, confirm the service is running:

sudo systemctl status netdata --no-pager
sudo ss -tulpn | grep 19999

By default, Netdata listens on port 19999. You can test locally from the VPS itself:

curl http://127.0.0.1:19999

If you see HTML output, the dashboard is responding.

Step 2: Secure dashboard access before regular use

The simplest safe choice is not exposing Netdata publicly at all. Good options include:

Allow access only from localhost and use SSH port forwarding
Expose it only over a private network like Tailscale
Put it behind Nginx with basic auth or another auth layer

For a fast beginner-friendly approach, use SSH port forwarding from your local machine:

ssh -L 19999:127.0.0.1:19999 ubuntu@your-vps

Then open http://127.0.0.1:19999 in your browser.

If you need web access behind Nginx, proxy it and restrict access:

location /netdata/ {
    proxy_pass http://127.0.0.1:19999/;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

Then add authentication or IP restrictions before treating it as production-ready.

Warning: Avoid opening port 19999 to the world with a simple firewall rule and calling it done.

Step 3: Focus on the resource charts that matter most

Netdata shows a lot. Start with the panels that solve common VPS problems.

CPU usage: Look for sustained high usage, not just brief spikes during deploys.

System load: Compare load average with CPU core count. High load on a tiny VPS can mean CPU, disk wait, or stuck processes.

RAM and swap: Watch whether memory stays near full and whether swap begins climbing steadily.

Disk usage: Look for filesystems trending upward over time, not just current percentage.

Disk I/O and latency: Heavy waits can make a server feel slow even when CPU seems fine.

Per-process charts: These help you identify whether Nginx, Docker, Postgres, or one noisy app is the main resource consumer.

Use Netdata together with command-line checks when you want confirmation:

free -h
df -h
top
vmstat 1 5
docker stats --no-stream

The dashboard becomes much more useful when you compare it against what you already know from shell tools.

Step 4: Verify the dashboard is giving you usable answers

After installation, you should be able to answer basic operational questions within a minute:

Is the root disk getting close to full?
Does memory pressure happen all day or only during certain jobs?
Are CPU spikes caused by one process or the whole system?
Is swap in occasional use or constantly active?

A good verification step is creating a small, harmless resource event and watching it appear. For example, run a package update or a short disk-heavy command, then confirm the charts change in the way you expect.

Rollback and recovery notes

If you decide not to keep Netdata, stop and remove it cleanly instead of leaving half-configured monitoring behind.

sudo systemctl stop netdata
sudo systemctl disable netdata

If you used the official installer, check its uninstall guidance for your install method. Also remove any firewall or reverse-proxy rules you added just for the dashboard.

If the dashboard seems to consume more resources than you expected on a very tiny VPS, measure before assuming. On most small servers, the operational visibility is worth the overhead, but it is fair to verify.

Troubleshooting common Netdata problems

The service installed, but the page does not load.
Check that netdata is running and listening on 127.0.0.1:19999 or the expected interface.

The dashboard is reachable locally, but not through Nginx.
Review the reverse-proxy path, trailing slash behavior, and whether auth or firewall rules are blocking access.

The charts show no Docker details.
You may need to confirm Docker is installed, running, and visible to the Netdata collectors.

I can see the problem, but not what caused it.
Use Netdata as the clue, then pivot to logs and process inspection to confirm the root cause.

What to do next

Once you can see resource pressure clearly, the next useful habit is responding safely when a server starts filling up. Continue with How to Fix Disk Space Issues on a Docker VPS Without Breaking Your Apps.