Installing Netdata

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

# Netdata will start on port 19999
systemctl status netdata

Accessing the dashboard

Open in your browser: http://YOUR_SERVER_IP:19999

⚠️ Block port 19999 from external access via a firewall, or set up an Nginx proxy with Basic Auth.

Nginx proxy for Netdata with authorization

server {
    listen 80;
    server_name monitor.example.com;

    auth_basic "Monitoring";
    auth_basic_user_file /etc/nginx/.htpasswd;

    location / {
        proxy_pass http://127.0.0.1:19999;
        proxy_set_header Host $host;
    }
}
htpasswd -c /etc/nginx/.htpasswd admin

Alerts in Telegram

# /etc/netdata/health_alarm_notify.conf
SEND_TELEGRAM="YES"
TELEGRAM_BOT_TOKEN="YOUR_BOT_TOKEN"
DEFAULT_RECIPIENT_TELEGRAM="YOUR_CHAT_ID"

What Netdata monitors out of the box

Category	Metrics
CPU	Load, temperature, frequency
RAM	Usage, swap
Disk	I/O, utilization, latency
Network	Traffic, packets, errors
Nginx/Apache	RPS, status codes, connections
MySQL/PostgreSQL	Queries/s, connections, slow queries

💡 Netdata collects metrics every second — that's 60 times more granular than Prometheus by default (every 60 sec).

Diagnosing common problems

The dashboard does not open even though systemctl status netdata shows active (running) — this is almost always the firewall. Netdata listens on port 19999, but UFW blocks everything not explicitly allowed by default.

curl: (7) Failed to connect to 203.0.113.10 port 19999: Connection refused

Check ufw status — if the port is not listed, either open it for your IP (ufw allow from YOUR_IP to any port 19999) or, better, close the port to the outside entirely and keep access only through the Nginx proxy with Basic Auth described above.

Telegram alerts never arrive even though the config looks correct. A common cause is that the service was not restarted after editing health_alarm_notify.conf: this file is read only at startup, hot reload does not apply to it.

systemctl restart netdata
# Check that Netdata sees the token and chat_id:
sudo -u netdata /usr/libexec/netdata/plugins.d/alarm-notify.sh test

Netdata vs Prometheus + Grafana

Criterion	Netdata	Prometheus + Grafana
Setup time	Minutes, out of the box	Hours — needs an exporter, scrape config, dashboards
Metric granularity	Once per second	Usually every 15-60 seconds
History retention	Hours-days on disk with no tuning	Months-years if storage is configured
Multi-server overview	Needs Netdata Cloud (external service)	Multi-server by architecture from the start

When Netdata does not fit

You need months of metric history for capacity planning — Netdata by default keeps data in memory and on disk for only a few hours or days; long-term storage needs an external backend like Prometheus.
You monitor a fleet of dozens of servers centrally — the free version of Netdata shows each server separately; a single dashboard needs Netdata Cloud or a separate Grafana stack.
You need complex aggregations and alerts based on arbitrary PromQL-like queries — Netdata's built-in alert language is simpler than PromQL and is not built for complex analytics.
The company requires keeping metrics on its own infrastructure with no external cloud service for a combined overview — free Netdata without Cloud shows only one server at a time, and that limit is architectural, not configurable.

Load on the server itself

Collecting metrics every second is not free: on a weak VPS with 1 CPU core and 512 MB of RAM, the netdata process itself can take up a noticeable share of resources, especially with every data-collection plugin enabled at once. On such plans it is worth disabling unused plugins in /etc/netdata/netdata.conf and lowering the chart update frequency from 1 to 2-5 seconds — the loss in responsiveness is minimal while the load drops noticeably.

Verifying the result

Open http://YOUR_IP:19999 (or the address through the Nginx proxy) — a dashboard with live CPU, RAM, disk, and network graphs must load.
Confirm direct access to port 19999 is closed from the outside: curl -m 3 http://YOUR_IP:19999 from another machine must time out or be refused.
Test alert delivery: temporarily set an artificially low threshold for a test alert and confirm the message arrives in Telegram.
Check autostart after a server reboot: systemctl is-enabled netdata must return enabled.

If you need long-term monitoring with months of history and dashboards across several servers, see the article on Grafana and Prometheus. To check site availability from the outside rather than just server metrics, see the article on website uptime monitoring.