Set Up Netdata for Real-Time Self-Hosted Server Monitoring

Why Netdata Beats the Alternatives for Self-Hosted Monitoring

Most server monitoring tools ask you to choose between simplicity and depth. You either get a basic dashboard that shows CPU and RAM in a bar chart, or you get a complex stack – Prometheus, Grafana, exporters, alert managers – that takes a full weekend to configure and another weekend to understand. Netdata sidesteps that trade-off entirely. It installs in under a minute, auto-detects nearly every service running on your machine, and starts streaming real-time metrics at one-second granularity without any additional configuration.

That one-second resolution matters more than it sounds. Most monitoring tools collect metrics every 10, 30, or 60 seconds. A CPU spike that lasts five seconds and crashes a process can vanish entirely from those graphs, leaving you staring at a clean chart while your server was quietly having a breakdown. Netdata captures those moments. It also stores historical data locally, builds its own metric database on disk, and ships with hundreds of pre-built alert rules tied to real performance thresholds – not generic placeholders you have to rewrite from scratch.

This guide walks through installing Netdata on a Linux server, configuring notifications, and setting up multi-node monitoring through Netdata Cloud.

Installing Netdata on a Linux Server

Netdata runs on virtually any Linux distribution – Ubuntu, Debian, CentOS, Fedora, Arch, and more. The fastest installation method is the official kickstart script, which detects your distribution, pulls the correct package, and handles dependencies automatically. Run this as root or with sudo:

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart.sh && sh /tmp/netdata-kickstart.sh

The script will prompt whether you want to connect the agent to Netdata Cloud. You can skip this for a fully offline setup – the local dashboard works without any cloud connection. Once installed, the agent starts automatically and the dashboard is available at http://your-server-ip:19999. Open that in a browser and you will immediately see live graphs for CPU usage broken down by mode, RAM consumption split between cached and actually used memory, disk I/O per device, network traffic per interface, and – if you are running services like Nginx, MySQL, Redis, or Docker – live metrics for those too, already populated without any manual configuration.

Configuring Alerts and Notifications

Netdata ships with a large library of pre-configured health alerts covering common failure conditions: disk space dropping below 10%, RAM usage climbing past 80%, network interface errors, dropped packets, and dozens more. These are not suggestions – they fire immediately when thresholds are crossed, writing to the system log by default. To actually get notified, you need to configure a notification method.

The notification configuration lives at /etc/netdata/health_alarm_notify.conf. Open it with your preferred editor and you will find sections for every major notification channel: email, Slack, PagerDuty, Telegram, Discord, and many others. For a self-hosted setup, pairing Netdata with a local push notification server keeps everything off third-party infrastructure. If you already run Gotify as a self-hosted notification server, Netdata supports it natively – you just paste your Gotify server URL and application token into the relevant fields in that config file. After saving, run sudo /etc/netdata/health_alarm_notify.conf test to trigger a test notification and confirm delivery.

Custom alert rules go into /etc/netdata/health.d/ as individual .conf files. The syntax is straightforward. A rule defines a metric, a calculation window, a warning threshold, and a critical threshold. For example, to alert when a specific disk stays above 85% utilization for more than two minutes, you write a rule referencing the disk.util chart, set the calculation to the average over 120 seconds, and define warning and critical values. Netdata’s documentation covers the full rule syntax, but the defaults cover most production scenarios without needing custom rules at all.

Connecting Multiple Nodes to Netdata Cloud

If you run more than one server, managing separate dashboards on different ports gets tedious fast. Netdata Cloud is a free web interface that pulls together all your agents into a single view. Despite the “cloud” branding, your metrics never leave your servers – only agent identifiers and metadata pass through Netdata’s infrastructure, while the actual metric data streams directly from agent to browser over a secure WebSocket connection.

To connect an agent to Netdata Cloud, create a free account at app.netdata.cloud, create a Space (their term for a workspace), and then claim your node. The claiming command is generated in the dashboard and looks like this: sudo netdata-claim.sh -token=YOUR_TOKEN -rooms=YOUR_ROOM_ID -url=https://app.netdata.cloud. Run that on each server you want to add. Within a few seconds, the node appears in your Cloud dashboard alongside any others already connected. You can group nodes into rooms by function – web servers in one room, database servers in another – and create room-level alert policies that apply across the whole group.

For teams or homelab setups where even the Cloud connection feels like too much exposure, Netdata supports a parent-child streaming architecture. One node is designated as the parent; all others stream their metrics to it in real time over your local network. The parent stores the data, aggregates it, and serves a combined dashboard. This requires no external accounts, no tokens, and no outbound connections. The configuration lives in /etc/netdata/stream.conf on both parent and child nodes, and the Netdata documentation walks through the exact lines to add on each side.

Locking Down the Dashboard and Managing Storage

By default, the Netdata dashboard is accessible to anyone who can reach port 19999. On a public-facing server, that is an immediate problem – the dashboard exposes detailed system topology, installed software, and performance patterns that have no business being visible to the open internet. The first step is restricting access. Edit /etc/netdata/netdata.conf and under the [web] section, set bind to = 127.0.0.1. This makes the dashboard only accessible from localhost, and you then reach it through an SSH tunnel or by putting Nginx or Caddy in front of it with authentication. A reverse proxy with basic auth or IP restriction takes about ten minutes to configure and closes the exposure entirely.

Metric storage is handled by Netdata’s built-in database engine, called dbengine. By default it stores several hours of high-resolution data and progressively downsamples older data to save space. The retention window is controlled by the dbengine multihost disk space setting in netdata.conf – the value is in megabytes. Setting it to 2048 gives you roughly several days of retention for a single-node setup; 10240 extends that considerably depending on how many metrics the agent is collecting. On a server monitoring dozens of containers and services, the metric count climbs fast, so monitor the /var/cache/netdata directory size during the first week and adjust accordingly.

Netdata also runs an optional Grafana integration via a plugin that exposes its metric database as a Grafana data source. This means you can keep Netdata doing what it does well – auto-discovery, alerting, real-time streaming – while building custom Grafana dashboards for long-term trend analysis or executive reporting without maintaining a separate Prometheus scrape infrastructure.

Once your agents are running, alerts are firing to the right channels, and the dashboard is locked behind a reverse proxy, Netdata fades into the background the way good infrastructure tooling should – until the moment a disk starts filling up at 3 a.m. and your phone buzzes before the service ever goes down.