--- title: "Homelab monitoring: what Uptime Kuma cannot see | Logdash" description: "Uptime Kuma inside the lab, heartbeats out of it for services behind NAT, and a Telegram alert when the power, router or ISP takes everything down." url: https://logdash.io/monitor/homelab --- # 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 ```bash #!/bin/sh # Usage: lab-heartbeat # 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 | Feature | Logdash | Uptime Kuma | | ----------------------------------- | ------------------------------------ | ----------------------------------- | | Sees LAN-only services | Through heartbeats your script sends | Directly, by HTTP, ping, TCP or DNS | | Alerts on a power cut or ISP outage | Yes, the silence is the alert | No, it is down or offline too | | Adding a service | One crontab line per service | A few clicks in the UI | | Notification channels | Telegram and webhook | Around 90 providers | | Maintenance | Nothing to update | One container to update and back up | | Cost | Heartbeats need Pro, $15 a month | Free 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. ## Keep reading [All platforms](https://logdash.io/monitor): One page per platform, each with what it already monitors, the gap, and a Telegram alert in three steps. [Raspberry Pi uptime monitor](https://logdash.io/monitor/raspberry-pi): Have the Pi send a heartbeat out to a hosted monitor every 10 seconds from cron, so a crash, a power cut or a dead home connection all end the same way: the heartbeats stop and an alert reaches your phone. [WordPress uptime monitoring](https://logdash.io/monitor/wordpress): Point an outside HTTP monitor at a URL that has to run PHP and reach MySQL, not only the cached homepage, and send the alert somewhere you read within minutes; no plugin is required. [Shopify store uptime monitoring](https://logdash.io/monitor/shopify): Shopify keeps its own servers up, so the useful thing to monitor is what Shopify does not watch for you: your storefront on your custom domain and any app or webhook endpoint you host yourself, each with an HTTP check that sends a Telegram alert when it stops answering. [Uptime monitoring](https://logdash.io/features/monitoring): HTTP checks as often as every 15 seconds. When one fails, Telegram tells you before your users do.