How to Use Netdata: The Beginner's Guide to Real-Time Server Monitoring
CodexFuse Team · 2026-10-31T03:57:27.257Z · 14 min read min read
Netdata shows you what your server is doing, second by second. One-line kickstart install, the first dashboard tour, one real health alarm, the Docker route, and the rule that keeps port 19999 off the public internet.
How to Use Netdata: The Beginner's Guide to Real-Time Server Monitoring
Learning how to use Netdata is the moment your VPS stops being a black box and starts telling you exactly what it is doing, second by second. Netdata is a free, open-source monitoring agent that installs on your server, collects thousands of metrics automatically — CPU, RAM, disk, network, every running service it can detect — and shows them on a live dashboard where every chart updates once per second.
This netdata tutorial runs the full beginner arc: one-line install with the official kickstart script, your first dashboard tour, one real custom alert, the Docker route, and the safe-access rules that keep port 19999 off the public internet. No database to configure, no exporters to wire, no YAML pipelines — the agent does the collecting and the rendering on the box itself.
One boundary first: Netdata watches the server from the inside. It tells you the machine is healthy, not that your website loads for a visitor in another city. For that outside view, run a website uptime monitor alongside it — internal metrics and external checks are the two halves of a complete monitoring setup.
You will build in this order: install the agent, open the dashboard, read the charts, set one alarm that warns you before a disk fills, then lock the dashboard down to localhost plus a reverse proxy. Nothing here assumes you have run a monitoring stack before — only that you have a Linux server you can SSH into.
How Do You Use Netdata in 5 Steps?
You use Netdata in five steps: install the agent with the one-line kickstart script, open the dashboard at port 19999, tour the auto-generated charts for your CPU, memory, disks and network, create your first health alarm in the health.d directory, and secure the dashboard so it is never reachable from the public internet without authentication. That is the whole beginner arc — everything else is refinement.
- Install: run the official kickstart script — it detects your distro, installs the agent, and starts a systemd service with daily auto-updates.
- Open the dashboard: visit
http://your-server-ip:19999and skip Cloud sign-in to use the local dashboard anonymously, or sign in for the Cloud view. - Tour the charts: system overview, disks, network, and applications — every chart updates every second with zero configuration.
- Set one alert: write a small alarm file in
/etc/netdata/health.d/so you get notified before a real problem, not after. - Lock it down: bind Netdata to localhost and reach it through an SSH tunnel or an Nginx reverse proxy with basic auth and TLS.
What Is Netdata, Exactly?
Netdata is a real-time infrastructure monitoring agent that runs directly on your server. It collects per-second metrics for the CPU, memory, disks, network interfaces, running processes, and any services it can auto-detect — Nginx, PostgreSQL, Docker, MySQL, and dozens more — and serves them through a built-in web dashboard on port 19999.
What makes it different from heavier monitoring stacks is what you do not have to do: no database to provision, no scrape targets to configure, no dashboards to draw. The charts are generated from the metrics automatically. Detailed metrics stay on disk for hours and summarized history for days, all stored locally — MassiveGrid's 2026 monitoring guide measured the agent's overhead as typically under 2% CPU on their test VPS.
Two roles exist in the Netdata world: the agent (the program on your server doing the collecting) and Netdata Cloud (the free SaaS view at app.netdata.cloud that lets you see multiple agents from one screen). Since v2.0 the dashboards are tied into Cloud sign-in, but the local agent dashboard still works standalone — ComputingForGeeks' April 2026 install walkthrough confirms you can click "Skip and use the dashboard anonymously" and keep everything local.
How to Install Netdata (Netdata Install via the Official Kickstart Script)
You install Netdata with the official kickstart script — one command that detects your OS, resolves dependencies, picks the best install method for your system (native packages first, static build as fallback), and registers daily auto-updates. A full netdata install takes about five minutes on a fresh server. Before anything else, you need a Linux server you can SSH into — if you have not provisioned one yet, start with a refresher on what is VPS hosting, then come back.
Update the system and make sure curl is present:
sudo apt update && sudo apt upgrade -y
sudo apt install -y curl
Then run the official installer on the stable channel:
curl https://get.netdata.cloud/kickstart.sh > /tmp/netdata-kickstart.sh && \
sh /tmp/netdata-kickstart.sh --stable-channel
The script prompts for any choices it cannot make itself. The netdata kickstart flags you will actually use are --non-interactive if you are scripting it, --release-channel if you want the nightly line, and --no-updates if you would rather patch on your own schedule. On privacy-sensitive servers, disable the anonymous usage ping by setting the documented environment variable — this is an env var, not a script flag:
DISABLE_TELEMETRY=1 sh /tmp/netdata-kickstart.sh --stable-channel
Verify the service is running, then open the dashboard:
systemctl status netdata
# then visit: http://your-server-ip:19999
Which install method should you pick? The short version:
| Method | When to use it | Trade-off |
|---|---|---|
| Kickstart script (recommended) | Any Linux server, any distro | Always current; runs a downloaded installer |
| Native repo package (repository.netdata.cloud) | When policy forbids curl-pipe installers | Stable, lags the stable channel slightly |
| Docker image (netdata/netdata:stable) | Container-first hosts; no host-level installs wanted | Full host metrics need the privileged mounts below |
| Distro apt package | Only when nothing else is possible | Distro repos lag upstream — avoid for Netdata |
What Does the Netdata Dashboard Show You?
The Netdata dashboard shows you every metric the agent collected, organized into sections you never had to define. Open http://your-server-ip:19999 and start at the top — the system overview gauges for CPU, memory, disk reads and writes, and network bandwidth, each moving live as the numbers change.
Your first five-minute tour:
| Section | What you see | The one number to watch first |
|---|---|---|
| System Overview | CPU per core, total RAM and swap, load average, uptime | Load average vs your core count |
| Memory | RAM, swap, page faults, kernel caches | Swap usage — it should be near zero |
| Disks | Throughput, IOPS, latency, space per mount | Free space on the root mount |
| Network | Bandwidth in/out per interface, packets, errors, drops | Dropped packets — nonzero means trouble |
| Applications | Per-process CPU, RAM, disk, network grouped by app | Which app owns the CPU spike |
| Services | Auto-detected Nginx, Postgres, Docker, and more | Whether your service even appears here |
Use the search box to find any chart by name, drag to zoom into any time window, and click a chart's alert icon to see the thresholds behind it. In Cloud-integrated dashboards the Alerts Configuration Manager can edit thresholds from the UI without touching files — the file method below works everywhere and is worth learning first.
How Do Netdata Alerts Work?
Netdata alerts are rules that watch a metric and raise a warning or critical state when a threshold holds — the agent evaluates them continuously, so an alert fires while you are asleep, not while you are staring at charts. The agent ships with pre-configured health alarms for common problems like CPU pressure, disk space, and memory exhaustion; they appear on the dashboard by default, but notifications go nowhere until you wire a channel.
Alert rules live in /etc/netdata/health.d/ as .conf files. Two rule types exist: template rules match a whole metric context (for example disk.space covers every mount at once) and alarm rules target one specific instance. Your own files are loaded before the stock rules, and custom files survive upgrades — never edit the stock files, because updates replace them. Use the agent's edit-config helper so you land in the right directory for your install type, and apply changes without a restart via sudo netdatacli reload-health.
Your first real alert — disk space, the beginner's classic. Create /etc/netdata/health.d/my_first.conf:
# Notify me while a disk is filling — not after it is full.
template: my_disk_space
on: disk.space
class: Utilization
type: System
component: Disk
lookup: max -1m percentage of avail
warn: $this < 20
crit: $this < 10
info: disk space is running low
to: sysadmin
Then tell Netdata where to send it. Open /etc/netdata/health_alarm_notify.conf — the file documents every channel from email to Telegram, Slack, Discord, and PagerDuty-style webhooks. For Telegram you set SEND_TELEGRAM="YES", your bot token, and the recipient ID; the official agent-notifications doc shows role-based routing such as role_recipients_slack[sysadmin]="#alerts", so one alarm can reach the right people per channel. Notification config changes take effect immediately — no restart needed.
Reload the health checks, then check the journal for a clean load:
sudo netdatacli reload-health
sudo journalctl -u netdata -n 50 --no-pager | grep -i health
Test the alarm by pointing the thresholds at an impossible level for a minute and watching it fire, then set the real numbers back. Keep notifications to one or two channels you actually read — five alert channels means you ignore all five.
How to Run Netdata in Docker
You run Netdata in Docker when the host is container-first and you would rather not install monitoring software on the bare system — but the container needs real privileges and mounts to see the host. This is the one Docker run where a plain image pull is not enough; Netdata has to reach /proc, /sys, and the Docker socket to monitor anything outside itself.
If Docker itself is new to you, run through the Docker beginner guide first — then the official container command is a single long docker run taken from Netdata's own Docker docs. A netdata docker deployment differs from a host install in one way: the mounts below are load-bearing, not optional.
docker run -d --name=netdata \
--pid=host \
--network=host \
-v netdataconfig:/etc/netdata \
-v netdatalib:/var/lib/netdata \
-v netdatacache:/var/cache/netdata \
-v /:/host/root:ro,rslave \
-v /etc/passwd:/host/etc/passwd:ro \
-v /etc/group:/host/etc/group:ro \
-v /etc/localtime:/etc/localtime:ro \
-v /proc:/host/proc:ro \
-v /sys:/host/sys:ro \
-v /etc/os-release:/host/etc/os-release:ro \
-v /var/log:/host/var/log:ro \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
-v /run/dbus:/run/dbus:ro \
--restart unless-stopped \
--cap-add SYS_PTRACE \
--cap-add SYS_ADMIN \
--security-opt apparmor=unconfined \
netdata/netdata:stable
Use the :stable tag on a production box — the untagged image tracks the latest build, which moves faster than you want your monitoring to. The dashboard lands at http://your-server-ip:19999 exactly as with a host install, and the official docs carry a Compose-file version of the same mounts for hosts that prefer Compose.
Netdata vs Grafana: Which One Do You Need?
Netdata vs Grafana is not really a versus — they answer different questions. Netdata is the agent: it collects, stores, alerts, and renders everything itself, with auto-generated dashboards and zero configuration. Grafana is the artist: a visualization layer that sits on top of data sources like Prometheus and shows you exactly the dashboards you — or someone else — designed.
| Netdata | Grafana | |
|---|---|---|
| Data collection | Built in — the agent collects everything itself | None — needs Prometheus or another source |
| Dashboards | Automatic, per-second, zero config | Hand-built panels you design yourself |
| Alerting | Built into the agent (health.d rules) | Grafana Alerting, wired to its data sources |
| Best for | One server or a fleet you want to see right now | Custom war-room views across many sources |
| Setup cost | One install command | Source plus Grafana plus dashboard design |
The honest beginner path: start with Netdata, because you get visibility in minutes. Graduate to Grafana when you have a data source worth painting — some teams export Netdata metrics into Prometheus and paint them in Grafana, keeping the easy collection and adding custom views. Grafana's lane is queued separately on this blog; this page is the Netdata lane.
How to Secure Netdata: the Never-Expose-19999 Rule
Secure Netdata by never letting port 19999 face the public internet unauthenticated — bots scan for open dashboards constantly, and an exposed Netdata leaks your server's internals to anyone who finds it. The rule is simple: Netdata listens on localhost, and you reach it through a tunnel or a reverse proxy with authentication.
Step one, bind Netdata to localhost only. Edit the config with the agent's helper — it resolves the right path for your install type:
sudo ./edit-config netdata.conf
# under the [web] section, set:
# bind to = 127.0.0.1
sudo systemctl restart netdata
ss -lntp | grep 19999 # confirm it listens on 127.0.0.1 only
The simplest safe access is an SSH tunnel from your laptop:
ssh -L 19999:127.0.0.1:19999 youruser@your-server-ip
# then open http://localhost:19999 in your browser
For permanent browser access, put Netdata behind Nginx with basic authentication and TLS — Netdata's own reverse-proxy docs walk through the upstream block, and the standard netdata nginx pattern that matches them is a small site file:
sudo apt install -y nginx apache2-utils
sudo htpasswd -c /etc/nginx/.htpasswd netdataadmin
# /etc/nginx/sites-available/netdata:
server {
listen 80;
server_name monitor.example.com;
location / {
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://127.0.0.1:19999;
}
}
sudo ln -s /etc/nginx/sites-available/netdata /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
Add TLS with your usual certificate process — Netdata's own Docker docs include a Caddy variant with automatic Let's Encrypt — then close port 19999 at the firewall so the dashboard is reachable only through the proxy. If you want single sign-on instead of basic auth, Netdata Cloud's sign-in mechanism is the path the official docs point to for shared access.
How to Disable Netdata Telemetry
You disable Netdata telemetry by setting the DISABLE_TELEMETRY environment variable to a non-zero value when you run the kickstart installer — netdata disable telemetry is a one-variable affair. Telemetry is enabled by default, and the opt-out is a documented installer option, not a hidden flag:
DISABLE_TELEMETRY=1 sh /tmp/netdata-kickstart.sh --stable-channel
On privacy-sensitive servers — client boxes, regulated environments, anything where an outbound ping is a paperwork event — run the install with the variable set from the start. There is no functional downside: the agent collects, dashboards, and alerts identically with telemetry off.
Beginner Mistakes That Waste Your First Week
| Mistake | Why it hurts | Do this instead |
|---|---|---|
| Exposing port 19999 to the internet | Scanners find open dashboards fast | Bind to localhost; tunnel or proxy with auth |
| Editing the stock health.d files | Updates overwrite them; your rules vanish | Write your own .conf files in health.d/ |
| Using the distro's old netdata package | Distro repos lag upstream releases | Use the official kickstart installer |
| Skipping alerts because the dashboard is pretty | You will not be watching when it matters | Set the disk-space alarm on day one |
| Alerting to five channels at once | Notification fatigue means you ignore all of them | One or two channels you actually read |
| Installing the untagged Docker image in prod | Surprise upgrades at container restart | Pin netdata/netdata:stable |
Sources
This guide was built from the official Netdata docs and independent 2026 walkthroughs, all fetched while writing:
- learn.netdata.cloud — "Install Netdata with kickstart.sh" (crawled October 31, 2026): kickstart.sh is the recommended install; OS detection; native packages preferred, static build fallback; daily auto-update cron by default; --non-interactive, --release-channel, --install-version, --claim-token, --reinstall/--uninstall flags; DISABLE_TELEMETRY env var.
- learn.netdata.cloud — "Install Netdata with Docker" (crawled October 31, 2026): netdata/netdata image, :stable tag, --pid=host --network=host, the full volume and mount list, dashboard at http://NODE:19999.
- learn.netdata.cloud — "Running Netdata behind Nginx" (reverse-proxy docs): upstream block, basic-auth password file, Cloud bearer protection option.
- learn.netdata.cloud — Alerts & Notifications docs (alert configuration ordering; overriding stock alerts; agent notifications): template vs alarm rules, user health.d loaded before stock, custom files survive upgrades, health_alarm_notify.conf role recipients and SEND_* flags.
- computingforgeeks.com — "Install Netdata on Ubuntu 26.04 LTS" (tested April 2026, Netdata v2.10.0): per-second metrics, "Skip and use the dashboard anonymously", static-build fallback, Nginx reverse proxy plus bind to 127.0.0.1.
- massivegrid.com — "Ubuntu VPS Monitoring: Set Up Alerts Before Problems Become Downtime" (September 2026): one-line install, dashboard overview, local retention, roughly 2% CPU overhead, notification channels.
- the.hosting — "How to Install and Configure Netdata for Server Monitoring": kickstart install, bind to 127.0.0.1, Nginx basic-auth pattern.
- hostmycode.com — "Linux VPS monitoring with Netdata: install, secure, and alert" (2026 tutorial): localhost-only vs proxy safe patterns, SSH tunnel, custom health.d alarms, never expose 19999.
Frequently Asked Questions
Is Netdata free to use?
Yes. The Netdata agent is open source and free, and Netdata Cloud offers a free tier that lets you view multiple agents from one browser screen (ComputingForGeeks describes it as a free SaaS layer for multi-agent views). The beginner arc in this guide — install, dashboard, alerts — costs nothing and needs no Cloud account at all.
What port does Netdata use?
Netdata serves its dashboard on port 19999 by default. Never expose that port to the public internet unauthenticated — bind the agent to localhost and reach it through an SSH tunnel or a reverse proxy with authentication, as shown in the security section above.
How much CPU and RAM does Netdata use?
Very little for what it does. MassiveGrid's 2026 monitoring guide measured roughly 2% CPU on their test VPS, and the installer downloads a static binary of about 180 MB when no native package exists (per ComputingForGeeks' April 2026 walkthrough). It is designed to monitor production boxes without becoming the load itself.
Do I need a Netdata Cloud account?
No. Cloud is useful when you run many servers and want one combined view, but the agent works standalone — ComputingForGeeks' install walkthrough confirms the dashboard offers "Skip and use the dashboard anonymously". Set up Cloud later only if you outgrow the single-server view.
How do I uninstall Netdata?
Re-run the kickstart script with the uninstall flag: sh /tmp/netdata-kickstart.sh --uninstall (the flag is documented in the official kickstart options table). Stop the service first with sudo systemctl stop netdata, and remove any reverse-proxy site file you added separately.