Back to blog
uptime kuma

Uptime Kuma is great. Here's what it can't tell you.

An honest look at the limits of self-hosted uptime monitoring: the watcher that shares fate with the watched, the 3 AM problem, and the difference between knowing your site is down and knowing your server is compromised.

Sandeep Sidhu

Sandeep Sidhu · Founder, AlertKick

4 min read
Uptime Kuma is great. Here's what it can't tell you.

Uptime Kuma has four limits that matter once it’s monitoring a business rather than a homelab: it runs on your own infrastructure, so a provider outage takes the monitor down with the app; an HTTP 200 says nothing about disk, CPU, or failed backups inside the box; it sends notifications but has no on-call rotations, escalation, or acknowledgements; and a perfect uptime graph says nothing about whether the server is compromised.

None of this is a knock on the tool. Uptime Kuma might be the most-recommended tool in self-hosted communities, and the recommendation is earned: one Docker command, a genuinely pleasant dashboard, dozens of notification providers, and no bill. For a homelab it’s close to perfect. But a pattern repeats: the tool that was perfect for the homelab quietly becomes the uptime monitoring for a business - the side project that got customers, the agency’s client sites, the startup’s production. At that point its limits stop being trivia. They’re worth knowing while it’s still a calm Tuesday.

1. The watcher shares fate with the watched

Kuma runs on your infrastructure - frequently on the very host, VPS provider, or network it monitors. When that layer fails, the monitoring fails with it, and a dead monitor is silent in exactly the way “everything is fine” is silent. The canonical failure: provider outage takes your app and your Kuma instance down, and the first notification comes from a customer.

Self-hosters patch this with a second Kuma watching the first from elsewhere - at which point you’re administering a monitoring estate, and the “who watches the watcher” recursion has begun. External monitoring isn’t a premium feature; it’s the definition of the job. The check has to come from infrastructure whose failures aren’t correlated with yours.

2. Up-or-down is the shallowest question

An HTTP 200 means the load balancer answered. It does not mean the disk isn’t at 97%, a process isn’t eating every core, the nightly backup ran, or the certificate renews before Saturday. Kuma covers some of this surface (cert expiry, keyword checks) but it fundamentally sees your servers from the outside - a status light, not a diagnosis. The questions that determine whether tomorrow has an outage are inside-the-box questions, and answering them takes an agent on the host, not a probe at the URL.

3. “Send a notification” is not “wake the right human”

Kuma posts to Telegram, Slack, or fifty other places. It lacks the layer that makes notifications survive contact with a team: on-call rotations, escalation policies, acknowledgements. Who is on duty? Who escalates if the first person does not ack in ten minutes? Did the 3 AM ping land in a muted channel? With one operator, these are trivia. With three, they determine whether an alert becomes an outage report. Bolting an escalation layer on top of Kuma adds another tool. That is how the DIY pile starts.

4. Up is not the same as safe

A server hosting a crypto miner shows a perfect uptime graph - miners are careful about that. A compromised box with an attacker’s SSH key in authorized_keys returns 200 on every check for months. Uptime monitoring and security monitoring are different senses, and no uptime tool - Kuma included, AlertKick included - substitutes for knowing who logged in, what changed on disk, and what your hosts are talking to. If the box matters enough to monitor, it matters enough to watch from the kernel.

5. The maintenance is real, just deferred

Kuma updates, database growth, backups of the monitoring itself, TLS on the dashboard, the reverse proxy in front. Each task is trivial. Together they are a standing tax on your attention. The software is free. The operator is not.

Keep Kuma. Or graduate deliberately.

If the stakes are homelab-sized, keep Kuma. The graduation moment is when the answer to “what happens if this is down for four hours and nobody notices?” involves money or customers.

AlertKick’s shape for that moment: external uptime checks and heartbeats from managed infrastructure (whose failures don’t correlate with yours), the agent answering the inside-the-box questions, rotations and escalation built in, and eBPF security covering the up-but-owned scenario - one platform instead of a pile. The free tier covers 10 monitors and heartbeats with no card, and unlike most free tiers, commercial use is allowed - so the graduation doesn’t have to start with an invoice.

Start free, point it at the things Kuma watches, and let the two run side by side. The comparison that matters is which one you trust the week something actually breaks, not the feature lists.

Frequently asked questions

What are the limitations of Uptime Kuma?
Four that matter once it monitors a business: it runs on your own infrastructure, so a provider outage takes the monitor down with the app; an HTTP 200 says nothing about disk, CPU, or failed backups inside the box; it sends notifications but has no on-call rotations, escalation, or acknowledgements; and a perfect uptime graph says nothing about whether the server is compromised. There is also ongoing maintenance - updates, database growth, backups of the monitor itself, TLS, and a reverse proxy.
Does Uptime Kuma have on-call rotations or escalation?
No. It can post to Telegram, Slack, and dozens of other places, but it has no on-call schedule, escalation policy, or acknowledgement layer. With one operator that is trivia; with three people it is the difference between an alert and an outage report, and bolting an escalation tool on top means running another tool.
What happens to Uptime Kuma when your hosting provider goes down?
If Kuma runs on the same host, provider, or network it monitors, it goes down with the app, and a dead monitor is silent in exactly the way 'everything is fine' is silent. The first notification comes from a customer. Running a second Kuma elsewhere to watch the first means administering a small monitoring estate of your own.
Is Uptime Kuma good enough for production?
For a homelab it is close to perfect. The graduation point is when the answer to 'what happens if this is down for four hours and nobody notices?' involves money or customers. At that point external checks from infrastructure whose failures are not correlated with yours, inside-the-box monitoring, built-in on-call, and security monitoring stop being optional.
Can uptime monitoring tell you if a server is hacked?
No. A server hosting a crypto miner shows a perfect uptime graph, and a box with an attacker's SSH key in authorized_keys returns 200 on every check for months. Uptime monitoring and security monitoring are different senses; no uptime tool substitutes for knowing who logged in, what changed on disk, and what the host is talking to.
Is there a free alternative to Uptime Kuma that allows commercial use?
AlertKick's free tier covers 10 monitors and heartbeats with no card required, and commercial use is allowed. It can run side by side with Kuma, pointed at the same things, so the comparison is made on which one you trust the week something actually breaks.
uptime kuma uptime monitoring self hosted monitoring