Raspberry Pi Home Server Monitoring in 2026

Raspberry Pi Home Server Monitoring in 2026

The Pi sitting on top of my router is, statistically, the most-used computer in the house. Plex serves the kids' shows. Pi-hole filters out 22% of all DNS traffic on the network. Home Assistant runs the lights, the thermostat, the morning coffee routine. When that Pi dies, the entire house notices within an hour and someone yells my name.

What it doesn't have, by default, is monitoring. The Pi-hole admin page shows you Pi-hole. Plex shows you Plex. top shows you what's running right now. None of them tell you "the SD card is dying" or "Home Assistant has been OOM-killed three times this week." That's how you find out about a problem the hard way: when the lights don't come on.

The standard answer is "install Prometheus + Grafana + Loki + Alertmanager." The standard answer is also too much. On a 4GB Pi 4 that stack uses 600-900 MB just to monitor itself, before it monitors anything else. That's bananas.

Here's the lighter version.

The Pi we're monitoring

Concrete setup for the rest of this post:

• Raspberry Pi 4, 4GB, running 64-bit Raspberry Pi OS (Debian-based, ARM64)
• Plex Media Server (native install)
• Pi-hole (in Docker)
• Home Assistant (in Docker, the supervised pattern via the Home Assistant container)
• One external USB SSD for media (the SD card is begging you to move heavy I/O off it)
• A second Pi (a 3B+) doing nothing important, included in this guide because most people have a "spare Pi" lying around

If your setup is close to that, you're in the right place. If you're running a 16GB Pi 5 with a NVMe HAT and the world's most over-engineered Kubernetes home cluster — different post.

What you actually want to know

A pragmatic alert list for a Pi home server, prioritized:

1. The Pi is unreachable. This is the headline. If the Pi is offline for 3 minutes, alert.
2. The SD card / disk is filling up. Logs or container images creep, then the OS goes read-only and everything dies in a confusing way.
3. Memory pressure. A 4GB Pi running three workloads can OOM-kill a container at 2 AM, and the Pi-hole or Home Assistant container will silently restart, and you won't notice until your lights stop working.
4. A specific container stopped. Plex, Pi-hole, Home Assistant — if one of them isn't running for 2+ minutes, you want to know.
5. CPU sustained high. Less critical, but if a Pi is at 95% CPU for 30 minutes it's almost certainly thrashing on something it shouldn't be.

You don't need 47 dashboards. You need those five things to fire.

Installing the agent on the Pi

This is the entire install:

curl -sSL get.netwarden.com | bash

The script detects you're on Debian-based ARM64 and pulls the arm64 agent binary. (32-bit Pi OS / armhf is also supported — the script picks the right binary either way.) It drops:

• The binary at /usr/local/bin/netwarden-agent
• A systemd unit file
• Default config at /etc/netwarden/netwarden.conf

It prompts for the agent token, starts the service, and that's the install. Confirm:

systemctl status netwarden-agent
sudo journalctl -u netwarden-agent --since "5 minutes ago"

You'll see the agent log its discovery pass — it'll find your Docker socket, list out the running containers, and start shipping metrics. Within 60-90 seconds, the host shows up in the dashboard.

Full reference is in the installation docs.

Real numbers on resource usage

The whole reason for this post is "without bringing up a heavy stack," so concrete numbers matter:

• Agent binary on disk: ~25 MB (single statically-linked Go binary, no runtime dependencies)
• RSS at idle: 18-30 MB on a Pi 4. I see 22 MB on mine running Plex + Pi-hole + Home Assistant.
• CPU: unmeasurable at the granularity of top. Below 1% sustained on a Pi 4. Spikes briefly during the collection cycle (every 30 seconds by default) and goes back to nothing.
• Network: a few KB per minute of compressed metrics out. Nothing meaningful.
• No JVM, no Python runtime, no Node.js, no Docker required. It's one binary.

Compare to a typical Prometheus + node_exporter + cAdvisor + Grafana setup on the same Pi: easily 500-800 MB RSS combined when idle, plus the disk usage of the time-series database growing by the day. On a 4GB Pi where Plex already wants 1-2 GB, that math doesn't work.

What it picks up on a Pi automatically

Once the agent is running, it auto-discovers and starts collecting:

• Host metrics: CPU (per-core), memory (used/free/cached/buffered), disk (per-mount, including the SSD if you have one mounted), network (per-interface), processes, system updates count
• Docker containers (because you have a Docker socket): per-container CPU, memory, network, state. Plex (if you ran it as a container), Pi-hole, Home Assistant — all picked up by name. Nothing to configure.
• Pi-hole itself shows up just as a Docker container — the agent will track its CPU/memory/restart-count. It does not parse Pi-hole's own DNS query metrics; that's outside scope.
• Plex running natively shows up as a process and you can graph its memory specifically.

Container monitoring is the same engine documented in the container monitoring docs. The reason it just works is that containers are discovered, not declared — same idea as the VM collector for Proxmox. You don't list what to watch.

The five alerts to set

Set these. Resist the urge to add more until one of them earns its keep.

1. Host unreachable (3 minutes)

The agent stops checking in. Could be the Pi rebooted, could be the network died, could be the SD card just bricked itself.

• Metric: host_status (or "agent not reporting")
• Duration: 3 minutes
• Notification: email + mobile push

The 3-minute threshold is deliberate. A clean reboot of a Pi 4 takes ~90 seconds. A 3-minute outage is something genuinely going wrong.

2. Disk usage above 85% on /

The SD card filling up is the silent Pi killer. Logs grow. Docker images stack. One day you apt upgrade and there's no room for the kernel package and the system goes read-only at midnight.

• Metric: disk_used_percent for mount /
• Threshold: > 85%
• Duration: 15 minutes
• Notification: email

If you've moved the data partition to an SSD, set the same alert on that mount too. Plex libraries grow.

3. Memory used above 90%

A 4GB Pi running three serious workloads will get tight at points. 90% sustained is the "you're going to OOM-kill something soon" line.

• Metric: memory_used_percent
• Threshold: > 90%
• Duration: 10 minutes
• Notification: email

You don't want this on push — it's not a wake-me-up event, it's a "look at this tomorrow" event. (The general approach to picking severity is in Alerts That Actually Page You.)

4. Container stopped: pihole / homeassistant

This is the one you'll be most thankful for. A Pi-hole container that crashed and didn't restart will silently kill DNS for the whole house, and unless you happen to look at the admin UI you won't notice for hours.

For each critical container:

• Metric: container_state (per-container, by name)
• Condition: state is not running
• Duration: 2 minutes
• Notification: email + mobile push

I set this for pihole and homeassistant. I do not set it for plex because Plex restarting briefly during an update is fine and not worth a 2 AM ping.

5. CPU sustained above 90% for 30 minutes

The catch-all "something has gone wrong and won't stop." A Plex transcode pegging at 100% for 5 minutes is fine. CPU at 90% for 30 minutes means a process is stuck.

• Metric: cpu_used_percent
• Threshold: > 90%
• Duration: 30 minutes
• Notification: email

The long duration is the whole point. Short CPU spikes are normal on a Pi running real workloads.

That's the full alert list. Five rules. They cover the actual ways a Pi home server breaks.

A small dashboard that fits on a phone

I have one dashboard pinned. On the phone, in landscape, it shows:

• Pi 4 (top row): host status pill, current CPU%, memory used/free, disk used on /, disk used on /mnt/ssd
• Containers (middle row): pihole, homeassistant, and the rest as state pills with current memory each
• Network (bottom row): rx/tx graph for the last hour
• System updates pending: a number with a tiny arrow showing trend

That fits on one screen. Tap any tile to drill into 24h history. Build it once with custom dashboards — the configuration sticks, it survives Pi reboots, it survives my phone.

Two screens of dashboard for a home server is too much. One is right.

Pi-specific gotchas

A few things that have bitten people running monitoring on a Pi:

• SD card writes. Time-series data is write-heavy. Self-hosting a metrics database on the same SD card is genuinely a way to wear out the card faster. The agent ships metrics out — it doesn't write a TSDB locally — so this is not a concern with this setup. If you go the Prometheus route, put the TSDB on the SSD.
• systemd-journald. Journald can grow without bound on a Pi if not bounded. Set SystemMaxUse=200M in /etc/systemd/journald.conf and run systemctl restart systemd-journald. The disk-usage alert above will eventually catch this, but better to bound it up front.
• Temperature. The agent doesn't currently alert on Pi CPU temperature. If you want to track that, vcgencmd measure_temp in a cron + your own webhook is fine. (It's on the roadmap as a built-in collector.)
• Two-Pi setups: the second Pi (the 3B+ doing not much) takes another host slot. Free tier is 1 host, so the second one needs the Solo plan. Honest about it.

When this isn't enough

If you're running anything that genuinely needs serious observability — a real production app, a multi-node K3s cluster, anything with revenue attached — a Pi home server isn't the right context for that conversation, and neither is this post.

But for "the Pi runs my house, and I want to know when it's about to fall over" — this is the whole answer.

Doing it right now

On the Pi:

curl -sSL get.netwarden.com | bash

Sign up at app.netwarden.com, grab a token, paste, done. The free tier covers one host forever. Set the five alerts above. Pin the dashboard to your phone's home screen. Get on with your life.

If you'd rather self-host the whole stack, the single-binary Bun build is in preview — it'll run on ARM64 with no external database, designed exactly for the kind of Pi setup this post describes. Watch the docs for the launch.

---

Keep Reading

• Monitor a Proxmox Cluster Without Datadog — When you outgrow the Pi and move to a real hypervisor.
• Self-Hosted Uptime Monitoring: The Honest Pingdom Alternative — Comparing Netwarden against Uptime Kuma, StatusCake, and HetrixTools for small fleets.
• Container Monitoring — How the Docker/Podman collector finds and tracks your containers.
• Alerts Setup — Wiring threshold alerts to email and mobile push.

Ready? curl -sSL get.netwarden.com | bash on the Pi. Ten minutes from now you'll have real alerts on the most-used computer in your house.