Linux Server Monitoring with Netdata and Alerts

By Kokil Thapa | Last reviewed: September 2026

Linux server monitoring with Netdata and alerts closes the gap between “the site feels slow” and knowing exactly which resource failed. You get per-second CPU, memory, disk, network, and application metrics without standing up Prometheus, Grafana, and half a dozen exporters first. On production Laravel and WordPress hosts I maintain, Netdata has caught runaway PHP-FPM workers, full disks, and MySQL connection spikes before clients noticed. This guide walks through install, hardening, alert tuning, and notification routing on a real Ubuntu web server.

For a lighter zero-config overview, see our companion piece on Netdata zero-config server monitoring. If you prefer a full metrics stack instead, read the Prometheus and Grafana monitoring stack guide.

What is Netdata and why use it for Linux server monitoring?

Netdata is an open-source monitoring agent that collects thousands of metrics every second. It ships with pre-built charts for CPU, RAM, swap, disks, network interfaces, systemd services, and common apps like MySQL, Redis, and Nginx.

Unlike a polling dashboard you check manually, Netdata evaluates health rules continuously. When disk usage crosses a threshold or load average spikes, it fires an alert. You configure where those alerts go.

On small teams—common on Nepal client projects—a single agent plus sensible notifications beats a complex observability stack you never finish configuring. I run Netdata alongside application health checks and nightly backups on shared EC2 hosts that serve multiple legal-tech portals.

Netdata fits servers running PHP 8.3 or 8.5, MySQL 9.7 or 8.4 LTS, Redis 8.10, and Laravel 12 or 13 applications—the stack I deploy most often. It does not replace log analysis or synthetic uptime checks. Pair it with Laravel health checks and uptime monitoring for end-to-end coverage.

How do you install Netdata on a Linux server?

The official kickstart script is the fastest path on Ubuntu 22.04 or 24.04. Run it as root on a freshly hardened host—follow our initial Ubuntu server setup guide first if the box is new.

Step 1: Run the kickstart installer

curl -fsSL https://get.netdata.cloud/kickstart.sh | sudo bash

The script detects your distro, installs dependencies, enables the systemd unit, and opens the local dashboard on port 19999. Verify the service:

sudo systemctl status netdata
curl -s http://127.0.0.1:19999/api/v1/info | head

Official install steps are documented at Netdata agent installation.

Step 2: Claim the node to Netdata Cloud (recommended)

During install, the script may prompt you to claim the node. Claiming connects the agent to Netdata Cloud for a central dashboard, alert history, and easier notification setup. You can also claim later:

sudo netdata-claim.sh -token=YOUR_CLAIM_TOKEN -rooms=ROOM_ID -url=https://app.netdata.cloud

Cloud is optional. Local-only monitoring works fine if you restrict dashboard access and route alerts yourself.

Step 3: Enable application collectors

Netdata auto-detects many services. For MySQL, create a read-only monitoring user:

CREATE USER 'netdata'@'localhost' IDENTIFIED BY 'strong_password';
GRANT REPLICATION CLIENT, PROCESS ON *.* TO 'netdata'@'localhost';
GRANT SELECT ON performance_schema.* TO 'netdata'@'localhost';
FLUSH PRIVILEGES;

Point Netdata at the credentials in /etc/netdata/go.d/mysql.conf. PHP-FPM and Nginx collectors activate when those services run on standard paths.

1. Install Netdata with the kickstart script on Ubuntu.
2. Confirm the systemd unit is active and the API responds locally.
3. Claim the node to Netdata Cloud or plan a local-only setup.
4. Enable MySQL, PHP-FPM, Nginx, and Redis collectors for your stack.
5. Lock down port 19999 before exposing the server to the internet.

How do you configure Netdata for production web servers?

Default settings work for a lab box. Production Laravel hosts need tighter retention, secured access, and tuned thresholds. I apply these changes on every server I hand over to a client through our Linux system administration service.

Harden dashboard access

Never leave port 19999 open to the world. Bind locally and tunnel via SSH, or put Nginx in front with basic auth and TLS:

# /etc/netdata/netdata.conf
[web]
    bind to = 127.0.0.1

Allow your IP only if you must expose the port. Match your UFW firewall rules for web servers so monitoring does not become an attack surface.

Tune memory and retention

Netdata stores recent history on disk with the dbengine backend. On a 2 GB VPS, cap retention to avoid disk pressure:

# /etc/netdata/netdata.conf
[db]
    mode = dbengine
    retention = 2d
    dbengine disk space MB = 256

Restart after changes: sudo systemctl restart netdata.

Monitor what actually breaks PHP apps

Watch these charts first on a typical stack:

• system.cpu and system.load — saturation under traffic spikes.
• disk.space — full partitions kill MySQL and logs silently.
• mem.available — OOM kills take down PHP-FPM without a clean error page.
• phpfpm.active_processes — pool exhaustion looks like a timeout to users.
• mysql.queries and mysql.connections — slow queries show up here first.
• web_log.requests — 5xx spikes often precede a support ticket.

On sister sites sharing a Deployer 7 pipeline—such as those behind Notary Kathmandu—identical Netdata configs make comparing nodes across releases straightforward.

For broader host metrics context, cross-read the Ubuntu server monitoring guide and our Ubuntu server setup guide.

How do you set up Netdata alerts that actually wake you up?

Collecting metrics is step one. Alerts are why you installed Netdata. The health engine reads rule files in /etc/netdata/health.d/ and fires notifications through channels you define.

Understand alert severity levels

Netdata uses WARNING and CRITICAL tiers. WARNING means investigate soon. CRITICAL means act now—disk full, service down, sustained load. Tune defaults so WARNING does not page you at 2 a.m. for a one-minute blip.

Create a custom disk alert

Default disk alerts exist, but explicit rules help on multi-partition servers:

# /etc/netdata/health.d/disks.conf
alarm: disk_space_usage
   on: disk.space
class: Utilization
 type: System
component: Disk
   os: linux
hosts: *
 calc: $used * 100 / ($avail + $used)
units: %
 every: 1m
 warn: $this > 80
 crit: $this > 92
 info: Disk space usage on $family

Reload health config without a full restart:

sudo netdatacli reload-health

Alert syntax reference lives in the official Netdata alerts and notifications documentation.

Route notifications to Slack or email

In Netdata Cloud, open Space settings → Notifications → Add notification. Connect Slack, email, PagerDuty, or Discord. For self-hosted email, edit /etc/netdata/health_alarm_notify.conf:

SEND_EMAIL="YES"
DEFAULT_RECIPIENT_EMAIL="ops@example.com"

# Slack example (webhook URL from your workspace)
SEND_SLACK="YES"
DEFAULT_RECIPIENT_SLACK="#server-alerts"

Test delivery:

sudo /usr/libexec/netdata/plugins.d/alarm-notify.sh test

Paste JSON alert payloads into our JSON formatter tool when debugging webhook integrations from Netdata Cloud.

Alerts worth enabling on day one

Start with these before writing custom rules:

• Disk space above 80% WARNING, 92% CRITICAL.
• Load average above CPU count for 5+ minutes.
• MySQL or PHP-FPM service not running.
• RAM available below 10% for 2+ minutes.
• Certificate expiry within 14 days if you monitor web_log SSL charts.

Pair alerts with automated server backup setup so a disk alert triggers both cleanup and restore planning—not panic.

How does Netdata compare to Prometheus and Grafana for server monitoring?

Both stacks solve observability. They target different team sizes and maturity levels. Netdata prioritises speed and defaults. Prometheus plus Grafana prioritises flexibility and long-term storage.

For a single Laravel app on a Rs 1,500/month VPS (~USD 11), Netdata is the practical default. When a client outgrows one box, migrate metrics to Prometheus—our complete Prometheus and Grafana setup guide covers that path.

On Adventure Third Pole Trek, a Laravel + Livewire booking app, Netdata caught a queue worker memory leak during a seasonal traffic spike. Prometheus would have worked too, but the client needed alerts that week—not a quarter-long observability project.

What are common Netdata monitoring mistakes on production Linux servers?

Installing Netdata takes ten minutes. Running it well takes discipline. These mistakes show up repeatedly on client servers I audit.

Exposing the dashboard without authentication

Port 19999 reveals process lists, connection counts, and internal paths. Bind to localhost or restrict by IP. Treat it like database access—not a public status page.

Alert fatigue from default thresholds

Out-of-the-box rules assume generic hardware. A 1 GB RAM VPS will WARN on memory constantly. Adjust health.d/ram.conf or silence noisy alarms until thresholds match your workload.

Monitoring without a response plan

An alert nobody acts on is noise. Document runbooks: disk full → rotate logs, expand volume, verify backups. Link monitoring to support and maintenance workflows so alerts create tickets, not Slack scrollback.

Ignoring correlated signals

High load plus flat CPU often means disk I/O wait—not a CPU problem. Check disk.io and system.io charts together. On Laravel apps, correlate PHP-FPM queue depth with MySQL slow queries.

Skipping security hardening on the host itself

Monitoring does not replace patching, fail2ban, or CIS-aligned baselines. Apply Ubuntu server hardening and review CIS benchmarks for server hardening before you declare the server production-ready.

Hosting choice matters too. Under-provisioned shared hosting hides metrics you need. Our domain registration and hosting guidance covers when a VPS with Netdata beats cheap shared plans for business-critical apps.

For security posture beyond metrics, read Ubuntu server security best practices and how to secure your website and server in Nepal.

Key Takeaways

• Install Netdata with the official kickstart script, then claim the node to Netdata Cloud for central alerts and history.
• Bind port 19999 to localhost or protect it with UFW and a reverse proxy—never expose the raw dashboard.
• Enable MySQL, PHP-FPM, Nginx, and Redis collectors so application metrics appear alongside host charts.
• Tune /etc/netdata/health.d/ rules and test Slack or email notifications before you need them at 3 a.m.
• Use Netdata for small fleets needing fast Linux server monitoring with Netdata and alerts; graduate to Prometheus when scale demands custom SLOs.
• Pair metrics with backups, health checks, and hardened baselines so alerts lead to action—not anxiety.

People Also Ask

Does Netdata work on Ubuntu 22.04 and 24.04?

Yes. The kickstart script supports both LTS releases and installs a systemd service that starts on boot. It also runs on Debian, CentOS Stream, and other major distros. Check the official installation docs for your exact OS version before deploying.

How much RAM does Netdata use on a small VPS?

With dbengine mode and a 256 MB disk cap, expect roughly 100–200 MB RAM on a typical web server. Lower retention further on 1 GB instances. The agent is lighter than running a full Prometheus stack on the same box.

Can Netdata send alerts to Telegram or Discord?

Yes. Netdata Cloud supports Discord, Telegram, Slack, email, PagerDuty, and webhooks. Self-hosted setups configure channels in health_alarm_notify.conf and reload the health engine after changes.

Is Netdata enough monitoring for a Laravel production app?

Netdata covers infrastructure and service-level metrics well. Add application health endpoints, queue monitoring, and synthetic uptime checks for full coverage. Netdata tells you the server is struggling; Laravel health routes tell you which feature broke.

Ship monitoring before the next outage

Linux server monitoring with Netdata and alerts takes an afternoon to install, harden, and tune—not a sprint to build observability from scratch. Start with disk, memory, load, and PHP-FPM pool alerts. Route them to a channel your team actually reads. Expand collectors and custom rules as traffic grows.

If you want Netdata deployed on production Laravel, WordPress, or legal-tech hosts with alerts, backups, and hardening handled together, contact us or review how we deliver ongoing ops through Linux system administration. You can also browse about my production DevOps work across Nepal and international client servers.