Ditching Prometheus and Grafana for Uptime Kuma and Netdata

I spent two years forcing Prometheus and Grafana onto a $5 Hetzner VPS. It was absolute overkill for a homelab with four Docker containers. To track basic uptime and CPU load, I was hemorrhaging 1.5GB of RAM just to keep the exporters running.

Last week, after my node_exporter container decided to eat an entire CPU core for breakfast, I finally ripped it all out.

A recent thread on r/selfhosted confirmed I wasn’t alone. u/ByteMeBites had the exact same realization: “I spent a weekend configuring Grafana dashboards only to realize I just wanted an email if my Nextcloud server died.”

The consensus in that thread? Use the right tool for the job. If you are running a massive Kubernetes cluster at work, keep Prometheus. If you just want to know when your Jellyfin server craps out, ditch it.

Here is the lightweight monitoring stack I deployed in 15 minutes. It uses about 50MB of RAM combined.

The Lifeboat: Uptime Kuma + Netdata #

We are swapping a heavy time-series database for a split stack.

Uptime Kuma handles external pings, HTTP status checks, and notifications. It is basically a self-hosted Pingometer. It uses SQLite, so there is no PostgreSQL bloat.

Netdata handles local system metrics. It does real-time monitoring out of the box with zero configuration. I haven’t tested Netdata’s Anonymous Statistics feature on ARM yet, but the community is genuinely split on whether it phones home too much. You can disable it, which I did.

Ripping Out the Old Stack #

First, nuke the old Hugo-static site monitor and its bloated pals.

docker stop prometheus grafana node_exporter
docker rm prometheus grafana node_exporter
docker volume rm prometheus_data grafana_data

Be ruthless. If you spent three hours building a custom Grafana dashboard that tracks disk I/O down to the millisecond, let it go. You will never look at it.

Deploying Uptime Kuma #

I run everything behind Cloudflare Tunnels, but Uptime Kuma works fine behind Nginx Proxy Manager or Traefik. Let’s spin it up.

mkdir -p /opt/kuma/data
docker run -d \
  --restart=always \
  -v /opt/kuma/data:/app/data \
  -p 3001:3001 \
  --name uptime-kuma \
  louislam/uptime-kuma:latest

Go to http://your-ip:3001 and set your admin password.

Add your services. For HTTP(s) checks, set the “Heartbeat Interval” to 60 seconds. Do not set it to 10 seconds. You are monitoring a homelab, not a high-frequency trading platform.

I route my notifications through a standard Discord webhook. It costs nothing and takes 30 seconds to set up in the “Settings” -> “Notifications” tab. Set a fallback email notification via a free SMTP relay like Brevo if you really want to be safe.

Dropping in Netdata #

Netdata used to be a pain to install via Docker because it needed host PID and NET_ADMIN capabilities. Now, they have a one-liner installer script that handles the bare-metal dependencies flawlessly.

wget -O /tmp/netdata-kickstart.sh https://my-netdata.io/kickstart-static64.sh
sh /tmp/netdata-kickstart.sh --dont-wait --stable-channel

Yes, I know. Running a curl-piped bash script is a cardinal sin in some circles. Read the script first if you are paranoid. I read it. It is clean.

By default, Netdata binds to port 19999. Block this port at your firewall immediately. You do not want your system metrics exposed to the public internet.

Instead, keep it bound to localhost. If you need remote access to your fancy real-time charts, use an SSH tunnel:

ssh -L 19999:localhost:19999 user@your-server-ip

Open your browser to http://localhost:19999 locally and you have the full dashboard. It updates every second and uses about 30MB of RAM.

Tying Them Together #

You do not actually tie them together. That is the beauty of this setup. Decoupling your alerting (Uptime Kuma) from your metrics (Netdata) means if your server is actively dying, the lightweight ping still gets out.

If you still want Grafana dashboards, Netdata exports a native Prometheus endpoint. You can run Grafana locally on your main desktop, point it at the Netdata endpoint over an SSH tunnel, and keep the heavy rendering off your server entirely.

Your mileage may vary depending on how many services you run. But if you are tired of Docker containers mysteriously failing because Prometheus ate all the RAM, try this.