Set Up Netdata as a Self-Hosted Real-Time Performance Monitor

Why Your Server Deserves Better Than a Dashboard You Check Once a Week

Most monitoring setups work the same way: collect data every minute or five, store it somewhere, display a chart that smooths over the spikes that actually matter. By the time you notice something went wrong, the process has already crashed, the disk is already full, or the latency has already been unacceptable for twenty minutes. Netdata takes a different approach – it collects metrics every second, displays them in real time, and starts working immediately after installation with no configuration required. It is the kind of tool that changes how you think about a server, not just how you watch it.

This guide walks through installing Netdata on a Linux server, accessing its web dashboard, configuring basic alerts, and connecting it to Netdata Cloud for remote monitoring. No prior monitoring experience is required. If you can SSH into a machine and run a shell command, you can have Netdata running in under five minutes.

What Netdata Actually Is

Netdata is an open-source performance monitoring agent that runs directly on your host machine. It collects system metrics – CPU usage, RAM, disk I/O, network throughput, running processes, and much more – and exposes them through a built-in web server on port 19999. There is no separate database to configure, no external metrics collector to wire up, and no dashboards to build from scratch. The entire stack ships in a single agent.

Netdata also has a cloud option called Netdata Cloud, which lets you view multiple nodes from one interface, share dashboards across a team, and receive alerts through integrations like Slack, PagerDuty, or email. The cloud layer is optional and free for basic use. The agent itself is fully functional without it, and all data stays local unless you explicitly connect to the cloud. For a self-hosted setup where privacy matters, that distinction is worth keeping in mind.

The project is actively maintained, with the agent available as a single-line installation script that handles dependencies, sets up a systemd service, and runs an update mechanism automatically. It supports Debian, Ubuntu, CentOS, Fedora, Arch, and most other mainstream Linux distributions. It also runs on Docker, which is useful if you want to monitor containerized workloads or keep the agent isolated from the host environment.

Installing the Agent

The fastest way to install Netdata is through its official kickstart script. Run the following command as root or with sudo on any supported Linux system:

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

The script detects your operating system, installs required packages, and starts the Netdata service automatically. Once it completes, open a browser and navigate to http://your-server-ip:19999. The dashboard loads immediately, with live charts already populating. No restart required, no configuration file to edit – the defaults are production-ready out of the box. If you are running a firewall, open TCP port 19999 using ufw or iptables, or keep the port closed and access it through an SSH tunnel for security.

Navigating the Dashboard and Understanding the Data

The default Netdata dashboard is divided into sections that map roughly to system components. The top of the page shows an overview panel with color-coded status indicators. Below that, charts scroll continuously as new data arrives every second. Each chart is interactive – you can hover over it to see exact values at a point in time, zoom in to a specific window, or pause the stream to inspect a spike without it scrolling away.

The CPU section breaks usage down by mode: user, system, softirq, steal (relevant if you are on a virtual machine), and iowait. High iowait is often a sign that a disk is under pressure, even when overall CPU usage looks moderate. The disk section shows read and write throughput separately, along with disk utilization and backlog – the backlog metric tells you how long I/O operations are waiting in queue, which is a more direct indicator of storage problems than throughput alone.

Network charts are organized by interface and include both bandwidth and packet rate. If your server runs any web-facing services, watch the packets-per-second charts alongside bandwidth – a sudden spike in packet rate without a corresponding bandwidth increase can indicate a small-packet flood or an early-stage DDoS. The Applications section, which uses Netdata’s process grouping feature, shows CPU, memory, and disk usage per application group rather than per individual process. You can customize these groups in /etc/netdata/apps_groups.conf to match your specific workload.

Netdata also auto-detects common services if they are running on the host: Nginx, Apache, MySQL, PostgreSQL, Redis, Docker, and many others. When it finds them, it adds dedicated dashboard sections with service-specific metrics – MySQL query rates, Redis hit ratios, Nginx active connections. This happens without any manual plugin configuration in most cases. If a service is not being detected automatically, check the Netdata logs at /var/log/netdata/error.log to see whether a plugin failed to connect.

Configuring Alerts

Netdata ships with a large set of pre-configured alerts covering common failure conditions: disk space above 80%, RAM usage sustained above 90%, network interface errors, and dozens of others. These alerts are defined in files under /etc/netdata/health.d/. Each file contains alert definitions written in a straightforward syntax that specifies a metric, a threshold, a severity level, and an optional custom message.

To send alert notifications, edit /etc/netdata/health_alarm_notify.conf. This file contains configuration blocks for email, Slack, PagerDuty, Telegram, and other channels. For email, set the DEFAULT_RECIPIENT_EMAIL variable and ensure your server has a working mail transfer agent like Postfix. For Slack, paste your webhook URL into the SLACK_WEBHOOK_URL variable and specify a channel. After saving the file, test notifications by running sudo -u netdata /usr/libexec/netdata/plugins.d/alarm-notify.sh test. If you need uptime-focused alerting rather than performance metrics, a tool like Uptime Kuma handles the endpoint-monitoring side that Netdata does not focus on – the two complement each other cleanly.

Connecting to Netdata Cloud and Long-Term Storage

To connect your agent to Netdata Cloud, go to https://app.netdata.cloud, create a free account, and click “Connect Nodes.” The interface gives you a claim token and a one-line command to run on your server. Once claimed, the node appears in your Cloud dashboard within seconds. All metric data continues to be processed and stored locally on the agent – Cloud only receives the metadata and alert state, not the raw time-series. This is a meaningful privacy design for anyone self-hosting on hardware they control.

By default, Netdata keeps detailed per-second data for a short window (around an hour, depending on available memory) and then uses progressively lower resolution for older data stored in its database engine. You can extend this by editing /etc/netdata/netdata.conf and adjusting the [db] section. Increasing the dbengine multihost disk space value tells Netdata to retain more history on disk. On a modest VPS with 20GB of free space allocated to Netdata’s database directory, you can reasonably keep several weeks of per-second data across all metrics – which is the kind of retention that makes post-incident analysis actually useful rather than a guessing exercise based on five-minute averages.

One thing Netdata does not do well on its own is long-term archiving to external systems for compliance or cross-node aggregation outside of Netdata Cloud. For that use case, Netdata supports exporting metrics to Prometheus, InfluxDB, Graphite, and other backends through its exporting engine, configured in /etc/netdata/exporting.conf. That opens the door to Grafana dashboards if your team already uses that stack – but for most individual operators running a handful of servers, the built-in dashboard and cloud integration cover everything without adding another service to maintain.