Self-Host Netdata for Real-Time Server Monitoring

Updated 10 November 2026 · Standard formula, shown below

Self-hosting Netdata gives you a live dashboard of server health, including CPU, memory, disk, network, and application metrics, without sending monitoring data to a hosted service. You’ll install the agent on a Linux server, open its local dashboard, and restrict access so monitoring does not expose your machine.

What You’ll Need

A Linux server you administer, with a supported distribution and an internet connection for installation.
A user account with sudo privileges, or root access.
The server’s IP address or hostname, plus SSH access if you are administering it remotely.
A browser on a computer that can reach the server. Netdata’s default dashboard listens on TCP port 19999.
If monitoring more than one server, a plan for secure remote access, such as a VPN or SSH tunnel. Do not expose the dashboard publicly without an access-control design.

Step-by-Step

Check the server and existing firewall. Connect over SSH if needed, then confirm the operating system and that you have administrative privileges. For example, run cat /etc/os-release and sudo -v. Check whether another service already uses port 19999, and note how the host firewall is managed. Avoid changing firewall rules over SSH unless you know how to preserve your current connection.
Install Netdata using its official installation instructions. Open Netdata’s current installation documentation and select the method for your distribution. The project provides an installation script; inspect the instructions before running it, and use the recommended command for the current release rather than copying an old command from a blog. Run the installer with the privileges it requests. It installs the agent and its service; the exact package and service details can vary by distribution.
Confirm that the agent is running. On systems using systemd, check with sudo systemctl status netdata. If the service is stopped, try sudo systemctl start netdata, then check its status again. Use sudo systemctl enable netdata if you want it to start automatically after a reboot. If your system does not use systemd, follow the service instructions for that operating system.
Open the dashboard locally first. On the server itself, visit http://localhost:19999 in a browser. From another computer on the same trusted network, try http://SERVER_IP:19999, replacing SERVER_IP with the server’s reachable address. The dashboard should show charts that update as the agent collects data. Allow a short time for charts to populate.
Choose how remote access will work. For private administration, a VPN is usually preferable to making the dashboard reachable from the public internet. Another option for occasional access is an SSH tunnel. From your workstation, run ssh -L 19999:localhost:19999 USER@SERVER_IP, then open http://localhost:19999 locally. Keep the SSH session open while using the tunnel. Replace the placeholders with your SSH username and server address.
Configure network access only where needed. If trusted devices must connect directly, create a firewall rule allowing TCP port 19999 only from the relevant private IP addresses or network. Firewall commands differ between systems, so use the tool already managing your firewall and verify the rule before disconnecting. Do not add a broad rule that allows port 19999 from every IP address. A firewall rule limits reachability; it is not a substitute for authentication or encryption.
Review access controls before relying on the dashboard. Check Netdata’s current security documentation for supported authentication, TLS, and proxy options in your installed version. If you put the dashboard behind a reverse proxy, configure the proxy and the agent together, and protect the connection with HTTPS and access controls. Do not assume that an obscure URL or a firewall alone secures a public endpoint.
Check collection and persistence. Browse the dashboard for the metrics you care about, such as CPU load, memory use, disk space, and network traffic. Netdata discovers many system metrics automatically, while application metrics may need additional collectors or permissions. Review the installed version’s configuration and retention settings; storage needs depend on the metrics collected and how long you keep them.
Test after a restart and document the setup. If safe to do so, restart the service with sudo systemctl restart netdata, then verify its status and reload the dashboard. Record the installation method, access path, firewall scope, and any configuration changes. This makes future updates and recovery easier.

Common Mistakes

Exposing port 19999 to the internet: A reachable dashboard can reveal operational details. Keep it private or use properly configured authentication, encryption, and network restrictions.
Assuming the dashboard is empty because installation failed: Some charts need time to collect data, and application metrics may require extra setup. Check basic system charts and the agent service first.
Using outdated installation commands: Installer options and packages can change. Follow the current project documentation for your operating system.
Opening a firewall broadly: Allowing traffic from all sources is rarely needed for a private monitoring dashboard. Limit access to a VPN, trusted subnet, or specific administrator addresses.
Confusing monitoring with alert delivery: A visible chart does not necessarily mean notifications are configured. Set up and test alert rules and delivery channels separately if you need warnings.

Tips

Start by monitoring one server and confirming the charts and access path before adding more hosts.
Use a VPN or SSH tunnel for remote administration when practical; keep direct dashboard access off public interfaces.
Check the disk space used by monitoring data and adjust retention to match available storage and your needs.
Keep the agent updated using the update method recommended for the way you installed it. Review release notes before changing a production host.
For multiple machines, check the current documentation for the supported centralized viewing approach. Keep each host’s agent and network access configured deliberately.

Troubleshooting

Dashboard does not load on the server: Check sudo systemctl status netdata and, on systemd systems, inspect recent logs with sudo journalctl -u netdata --since "15 minutes ago". Confirm the service is listening on port 19999 and that the address in the browser is correct.
It loads locally but not from another device: Confirm the server’s private IP, routing, and firewall rules. Make sure Netdata is configured to accept connections on the intended interface. Do not solve this by opening the port to the entire internet.
The SSH tunnel fails: Check that SSH works independently and that the remote service is listening on the server’s loopback address and port 19999. If local port 19999 is already occupied, use another local port in the tunnel command, such as -L 20000:localhost:19999, then browse to http://localhost:20000.
Charts are missing or flat: Wait briefly, refresh the page, and check whether the metric exists on the host. Review agent logs and collector configuration. Some metrics need extra permissions, software, or configuration to be collected.
Service will not start after an update: Read the service logs for configuration or permission errors, then compare your local configuration with the current version’s documentation. Back up configuration before making changes, and avoid deleting data directories as a first troubleshooting step.

Frequently Asked Questions

Is Netdata free to self-host?
Netdata provides a self-hosted agent. Check the project’s current licensing and product documentation for details about features and any optional services.

Does Netdata send my metrics to the cloud?
A local agent can provide a dashboard from your own server. Review your installation and configuration to confirm whether any optional cloud connection or remote service is enabled.

Can I monitor several servers?
Yes. Install an agent on each server, then use a supported centralized viewing setup or access each agent securely. Follow current documentation for the topology and version you use.

Is port 19999 safe to expose publicly?
Do not expose it without a deliberate security configuration. Prefer a VPN or SSH tunnel, or use suitable authentication, HTTPS, and network restrictions.

Will Netdata keep historical metrics?
It stores data according to its configuration and retention settings. How much history is available depends on the installed version, storage, and configured retention.

Do I need to install a separate database?
Not for a basic agent and local dashboard. Extra components or storage choices may be relevant for particular multi-server or long-term monitoring designs.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.