homelab

Uptime Kuma: Find Out If Your Homelab Is Still Alive

4 min readByArnau Ruiz

Somewhere in your homelab, Pi-hole is quietly filtering ads, a couple of containers are doing their thing, maybe k3s is running something you forgot about. Great, until one of them dies at 3am and you find out three days later when someone asks why the ad blocking stopped working. Uptime Kuma fixes that with one dashboard that pings everything and actually tells you when it’s down.

What it does

  • Pings HTTP(S) endpoints, TCP ports, DNS, or anything with a heartbeat, on whatever interval you set
  • Shows uptime history and response time graphs per monitor, so you can actually see if something’s getting slow before it dies completely
  • Sends notifications the moment something goes down, not the next time you happen to check
  • Gives you a public status page if you want one, useful if other people in the house rely on your homelab and blame you personally when it’s down

Get it running

docker run -d --name uptime-kuma 
  -p 3001:3001 
  -v uptime-kuma-data:/app/data 
  --restart unless-stopped 
  louislam/uptime-kuma:latest

Open http://your-server-ip:3001, set up your admin account, and you’re in.

Add your first monitor

Click Add New Monitor. Pick a type (HTTP for a website, TCP Port for a service that doesn’t speak HTTP, Ping for a plain reachability check), give it the address, and set a check interval. 60 seconds is a reasonable default, you don’t need to hammer your own Pi-hole every 5 seconds to know it’s alive.

Repeat for everything that matters: Pi-hole, any web UI you’re exposing through Portainer, your k3s services, even the router if you want to know when your internet itself drops.

Notifications (the part that actually matters)

A dashboard nobody looks at is useless. Go to Settings, Notifications, and connect Telegram, Discord, or plain email, whichever you’ll actually see on your phone. Attach that notification to each monitor, and Uptime Kuma will tell you the moment something drops, instead of you finding out because someone else mentioned the ad blocking stopped working.

Set the retry count to at least 2 or 3 before it fires a notification. Otherwise one flaky network blip at 4am will page you for absolutely nothing, and you’ll start ignoring the alerts, which defeats the entire point.

Building a status page people actually check

Under Status Pages, create a new one and drag your monitors onto it, grouped however makes sense (Network, Media, Homelab Infra, whatever fits). It generates a clean public URL you can share with anyone who relies on your setup, so “is the server down?” gets answered by a bookmark instead of a message to you. You can also set a custom domain for it if you want it to look less like a self-hosted side project.

Maintenance windows, so you stop getting paged for yourself

If you’re about to reboot a server or push an update, Uptime Kuma will (correctly, but annoyingly) flag it as down the second it goes. Under Maintenance, schedule a window covering your planned downtime, and monitors tied to it get suppressed from alerts and the status page during that time. Nothing worse than training yourself to ignore notifications because half of them are your own doing.

Uptime Kuma vs the alternatives

Healthchecks.io and Better Stack both do similar things as hosted services, meaning no container to maintain but also your uptime data living on someone else’s server, and usually a free-tier monitor limit. Uptime Kuma trades that convenience for full control and no limits, at the cost of being one more thing in your homelab that needs its own uptime monitoring, which admittedly sounds like a joke but is a genuinely fair point people raise. If you already run Uptime Kuma to watch everything else, that’s one Docker container, and the tradeoff is worth it.

Related reading

Similar Posts