Homelab monitoring

Homelab monitoring needs two layers, detailed checks inside the lab, usually Uptime Kuma, and one watcher outside it, because a monitor that shares your power, router and internet line goes silent exactly when those fail.

Most homelabs end up with Uptime Kuma in a container, and it is a good choice. It checks every VM, container and device on the LAN by HTTP, ping, TCP or DNS, sends to around 90 notification providers and costs nothing. The gap is where it lives. When the power goes, the router reboots into a bad config or the ISP drops you for an hour, Kuma goes down with everything else, or it sees the failure and has no route out to tell you. You find out when you get home, or when someone in the house asks why Jellyfin is broken.

The fix is not replacing Kuma. It is one thing outside the lab that expects to hear from it. Services behind NAT cannot be checked from the internet without opening ports, so the lab pushes instead: a small script checks each service locally and sends a heartbeat out only when the service answered. No port forwarding, no tunnel, no public IP.

Heartbeats out of the lab

/usr/local/bin/lab-heartbeat
#!/bin/sh
# Usage: lab-heartbeat <local url> <logdash monitor id>
# Pings Logdash only while the local service answers. Six pings a minute,
# because a Pro push monitor expects one in every 15-second window.
for i in 1 2 3 4 5 6; do
  curl -fsS -m 2 -o /dev/null "$1" &&
    curl -fsS -m 2 -o /dev/null -X POST "https://api.logdash.io/ping/$2"
  sleep 10
done

# chmod +x it, then crontab -e on an always-on box, one line per service:
# * * * * * /usr/local/bin/lab-heartbeat http://192.168.1.20:8096/ JELLYFIN_MONITOR_ID
# * * * * * /usr/local/bin/lab-heartbeat http://192.168.1.30:8123/ HASS_MONITOR_ID

Push monitors are a Pro feature, $15 a month for up to 50 services, and on Pro Logdash expects a heartbeat in every 15-second window. Cron runs at most once a minute, so the script loops six times with 2-second timeouts, which keeps every gap under 15 seconds. One missed window is an alert, so run it on a box with a wired connection. A flaky Wi-Fi link turns into pairs of down and up messages.

A homelab monitoring stack that covers both failures

  • Inside: Uptime Kuma for every container, disk and device. Fine-grained, free, and on the LAN where it can reach everything.
  • Outside: one heartbeat per service that matters, sent by the script above. When all of them go quiet at once, the problem is power, the router or the line, not a service.
  • Public services: anything you expose through a reverse proxy or a tunnel can take a plain HTTP monitor instead. Five of those run on the free plan, checked every 5 minutes. Logdash refuses private addresses, so a 192.168 URL has to use a heartbeat.
  • A status page: the free plan includes one public page, so the household can check it before they message you.
  1. Create the push monitors One service per thing you care about, monitor mode set to push. Copy each id into its crontab line.
  2. Install the script Save it, make it executable, add the crontab lines. Within a minute every monitor is green and Telegram gets an up message for each, so you know the path works.
  3. Unplug the WAN cable Every heartbeat stops at once. Within 30 seconds Logdash marks each monitor down, and the Telegram alerts land on your phone over mobile data, one per service, while the whole lab is still offline.

Logdash vs Uptime Kuma in the lab

FeatureLogdashUptime Kuma
Sees LAN-only servicesThrough heartbeats your script sendsDirectly, by HTTP, ping, TCP or DNS
Alerts on a power cut or ISP outageYes, the silence is the alertNo, it is down or offline too
Adding a serviceOne crontab line per serviceA few clicks in the UI
Notification channelsTelegram and webhookAround 90 providers
MaintenanceNothing to updateOne container to update and back up
CostHeartbeats need Pro, $15 a monthFree on hardware you already run

When Uptime Kuma alone is the better pick

  • You only care about single services failing, and you would notice a power cut or a dead line anyway because you are at home.
  • You want the outside watcher free. Kuma plus a free Healthchecks.io account, 20 jobs with a Telegram integration, covers both layers for nothing.
  • You want ping, TCP and DNS checks on every device. Logdash does HTTP and heartbeats, nothing else.
What is the best setup for homelab monitoring?
Two layers. Uptime Kuma or similar inside the lab for every service, and one watcher outside it that alerts when the lab goes quiet. Without the second layer, a power cut or an ISP outage produces no alert at all.
How do I do homelab uptime monitoring without opening ports?
Push instead of pull. A script on the LAN checks each service locally and POSTs a heartbeat out to a hosted monitor. Outbound HTTPS needs no port forwarding, no tunnel and no static IP.
Should I run Uptime Kuma in my homelab?
Yes, it is the best free tool for checking things on a LAN. Just do not make it the only monitor, because it shares power, router and internet with everything it watches.
What goes in a homelab monitoring stack?
An inside checker such as Uptime Kuma, an outside heartbeat watcher, a status page for the people who use your services, and alerts on a channel you read on your phone. Grafana and Prometheus come later, if you want graphs of the hardware.

Point it at your own URL and watch it for real.