The home network monitoring stack I actually look at every day

Most home network monitoring stops at “is my internet up?” That’s the wrong target. The internet is almost always up. What goes wrong on a home network is more interesting and harder to see: a device starts phoning home to a new analytics service, a video call degrades because something else is saturating the uplink, a camera quietly starts uploading far more than it used to after a firmware update.

I run two off-the-shelf tools on a Raspberry Pi 5 to make this visible: Pi-hole for DNS, and ntopng for per-device traffic. None of it is novel. All of it is useful. This post is the setup and the things I got right and wrong building it.

The setup

The Pi 5 is an 8GB board with an NVMe drive in an Argon ONE case — the same machine that hosts the rest of my home services (home automation, media, a handful of helpers). The monitoring tools are containers in the same Docker compose stack. Resources are not a constraint.

Pi-hole runs as the LAN’s DNS server. The Eero hands out the Pi’s address via DHCP, so every DNS query from every device lands at Pi-hole first. Pi-hole logs it, optionally blocks it against a list of known ad and tracking domains, and forwards the rest upstream. I run the upstream through dnscrypt-proxy to Cloudflare’s 1.1.1.1 over HTTPS, so the queries that do leave the house leave encrypted.

ntopng is the part that took the most work, because consumer mesh routers don’t give you a span/mirror port to tap. Eero is no exception — there’s no “mirror all traffic to this port” setting. So instead of mirroring, I put the Pi inline: it’s a transparent Layer 2 bridge sitting between the ISP modem and the Eero’s WAN port. Two USB 3.0 gigabit NICs plus the onboard NIC, bridged in the kernel, with ntopng listening on the bridge interface. Every packet to and from the internet crosses the bridge, so ntopng sees all of it — per-device, per-protocol, per-flow — without the Eero having to cooperate at all. Measured added latency is under half a millisecond, which is imperceptible. There’s a GPIO-driven relay as a hardware bypass so that if the Pi ever dies, traffic falls through to the Eero directly and the house keeps its internet.

That inline-bridge trick is the whole reason this works on a mesh that was never designed to be observed.

What I actually look at

ntopng has its own web UI; I didn’t bolt on a separate dashboard layer. The morning routine is fast — open two bookmarks, scan a couple of numbers, close them.

Blocked queries overnight (Pi-hole). Pi-hole’s total block count. If it’s dramatically higher than usual, something on the network started phoning home more often — a new app, a vendor adding a telemetry endpoint to an existing one, occasionally something more interesting.

Top talkers in the last 24 hours (ntopng). Per-host outbound bytes. Useful for noticing when a device’s behavior changes. A laptop uploading more than usual is usually a backup. A camera uploading more than usual is something to investigate.

Per-device throughput vs. recent baseline (ntopng). ntopng tracks per-host history and can alert when a host crosses a threshold. A device that’s always done 100 MB/day isn’t interesting. A device that’s done 100 MB/day for a month and is suddenly doing 300 MB/day is.

The patterns that matter

A few things to get right if you’re building something similar.

Make the DNS server the LAN’s DNS server. Half-measures — Pi-hole as a “secondary,” devices that hard-code their own DNS, IoT gear that bypasses DHCP-provided DNS — defeat the visibility entirely. For devices you can’t control, point their gateway at Pi-hole and block outbound DNS-over-HTTPS at the edge so they can’t route around it.

If you can’t mirror, bridge. The instinct on a managed switch is to set up a SPAN port. Consumer mesh gear doesn’t offer that. An inline transparent bridge gives you the same visibility — every WAN packet — at the cost of putting a Pi in the critical path. Build the bypass before you need it.

Don’t try to monitor everything. I tracked a long list of metrics early on and used a handful. The dashboards I built for the rest just sat there unopened. Pick the few numbers that matter and put them where you’ll actually see them.

Make the data reachable everywhere you’d realistically check it. Mine is reachable on the LAN by address and remotely over Tailscale. If I had to remember a port and an IP or SSH in to read raw logs, I wouldn’t check it — and the first version of this setup, which required exactly that, I abandoned within a month.

The lesson

Network monitoring at home is only useful if the data is one click away. The bar for “useful” is much lower than people think — a couple of numbers in a morning routine — but it requires the visibility to be in your routine. This setup became part of mine because the data is good and the access is fast. The setup before it didn’t, and so it taught me nothing.

Build the stack you’ll actually look at. The rest is implementation detail.