Uptime Kuma is great. Here's when you should use a hosted service instead

Uptime Kuma is genuinely excellent software. It's free, open-source, has a good UI, supports dozens of monitor types, includes status pages, and runs on anything from a Raspberry Pi to a Hetzner VPS. If you want a self-hosted uptime monitor, it's hard to argue with.

I've used it. I still have it running. But I've also learned where its limits are, and there are specific situations where a hosted service is the right tool for the job.

---

The fundamental problem with self-hosted monitoring

If Uptime Kuma is running on the same server as the thing you're monitoring, and that server goes down, Uptime Kuma goes down too. You lose your monitoring at exactly the moment you need it.

This seems obvious, but people run into it more than you'd expect. The fix is to run Uptime Kuma on a different machine. But now you're running an extra server just for monitoring — one you need to keep updated, backed up, and running. The operational overhead isn't huge, but it's not zero.

There's a subtler version of this problem too. If your monitoring runs in the same network, datacenter, or cloud region as your services, a regional outage or network partition can take out both your services and your monitoring simultaneously. You need your monitoring to be genuinely external.

Uptime Kuma doesn't take screenshots

Uptime Kuma's HTTP monitor, like most ping monitors, checks status codes. It doesn't run a browser, doesn't execute JavaScript, doesn't take screenshots, doesn't diff visual output.

If your monitoring strategy is "HTTP 200 means working," you have a gap. See the rest of this blog for a long discussion of why that's not true for modern web apps.

This isn't a criticism of Uptime Kuma — it's a different tool designed for different things. But it means you need something else to cover the visual failure modes.

When self-hosted makes complete sense

If you're monitoring internal services — databases, internal APIs, home lab services, self-hosted applications that aren't externally accessible — Uptime Kuma is perfect. Hosted services can't reach your internal network anyway. Self-hosted is your only option.

If you want full control over your monitoring data and don't want it going through any third party, self-hosted is correct.

If you're monitoring dozens of services and want the full feature set (status pages, notification channels, DNS monitoring, Docker container monitoring), Uptime Kuma covers a lot of ground.

When hosted makes sense

For external URLs — the ones your users actually hit — a hosted monitoring service is genuinely external and isn't affected by your infrastructure going down. That's the main argument.

For visual screenshot monitoring, where you need headless Chrome and object storage for screenshot history, the infrastructure cost and complexity of self-hosting is significant. Running Chrome instances at scale is memory-intensive.

The setup that works well for me: Uptime Kuma for internal services and network-level monitoring, GrabDiff for external URLs where I need visual checks and true external monitoring. They complement each other without much overlap.