Who Watches the Watchers: Uptime Kuma for the Home Lab

G'day! Welcome back. Somewhere along the way this home lab quietly turned into a small fleet: two Pi Zero 2 Ws, a Pi 4, a Dell laptop moonlighting as a server, a Hetzner box, and a pile of cloudflared tunnels and Tailscale nodes tying it all together. Great, until one of them falls over at 2am and nobody finds out until the coffee doesn't grind because the automation silently died.

We already push MQTT fleet alerts to Telegram for device-level events. What was missing was the boring, essential layer underneath: is the service even up? Today we're wiring in Uptime Kuma — a self-hosted status page and uptime monitor — to keep an eye on every yazan.me endpoint in the lab. Let's crack into it.

Why Not Just Trust Cloudflare

Cloudflare Tunnels are solid, but a tunnel staying connected doesn't mean the service behind it is healthy. Home Assistant can wedge, a Docker container can crash-loop, Postgres can run out of disk — and the tunnel will happily keep forwarding requests into a 502 all night. We wanted something checking the actual HTTP response, not just the pipe.

Where It Lives

Monitoring the lab from inside the lab is a bit of a blind spot — if the Dell server dies, so does the thing watching the Dell server. So Uptime Kuma runs on the Hetzner box instead, the same ubuntu-4gb-nbg1-1 CX23 already fronting live client sites via CloudPanel. It's outside the home network entirely, reachable over the public internet, and checking in on everything else from the outside — which is exactly the vantage point that matters.

Setting It Up

Step 1: Run the container. One line, one volume for persistence:

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

Step 2: Front it with CloudPanel + dploy's usual reverse-proxy pattern, or just point a subdomain at it — status.yazan.me — through the same Cloudflare setup already handling the client sites on that box.

Step 3: Add a monitor for every service worth caring about. HTTP(s) checks for the cloudflared-fronted stuff — home.yazan.me, frigate.yazan.me, music.yazan.me, media.yazan.me, litellm.yazan.me — and TCP ping checks for the Tailscale SSH endpoints (ssh.zero.yazan.me, ssh.mqtt.yazan.me, and the rest) so a Pi going dark shows up even if it has nothing web-facing at all.

Wiring Up Alerts

Kuma's notification list covers most things, but Telegram was the obvious pick since it's already the alert channel for MQTT fleet events — one app, one place to glance. Bot token and chat ID go into the notification config once, then get attached to every monitor:

• Settings → Notifications → Telegram → paste bot token + chat ID

• Apply that notification to each monitor (or set it as default for new ones)

• Set a sane retry count (we run 3 retries, 60s apart) so a single flaky check over cloudflared doesn't page us for nothing

Now a Home Assistant crash and an MQTT broker going quiet land in the exact same Telegram thread — one glance tells the whole story of what's actually wrong in the lab.

The Bonus: A Public Status Page

Kuma also builds a public status page for free, which turned out more useful than expected — a single status.yazan.me link to send anyone (or check yourself from a phone on someone else's Wi-Fi) instead of trying to remember which of eight subdomains might be misbehaving.

The Verdict

Uptime Kuma is a small, unglamorous piece of infrastructure, and that's exactly the point — it's the thing that tells you something's wrong before a guest asks why the smart lights aren't responding. Running it off-site, on the Hetzner box, closes the one blind spot self-monitoring always has: watching yourself.

Fifteen minutes to stand up, and you'll wonder how the lab ran without it. Cheers!

"If you've got any questions or need a hand wrangling your own setup, don't hesitate to reach out at [email protected] or connect with me via www.yazan.me. I'm always keen to help out!"