Uptime Kuma alternative (and the watcher for Kuma itself)

What Uptime Kuma does well

Uptime Kuma is genuinely excellent software, and it is free in the way that matters: MIT licensed, self-hosted, no account, no seat count, no upsell. If you already run Docker somewhere, you can have it monitoring your whole stack in about five minutes, and nobody can ever raise your price or deprecate your tier.

• It is unlimited by construction. Ten monitors or four hundred, one user or the whole team, it costs the same because it costs nothing.
• The notification provider list is enormous. Dozens and dozens of integrations, including plenty of niche ones no hosted service will ever bother to add.
• It supports intervals as short as you dare, because you own the machine doing the checking.
• It runs on your network, so it can reach things nothing on the public internet can reach: an internal API on 10.0.0.x, a database port behind the firewall, a printer.
• It has push (heartbeat) monitors, status pages, maintenance windows, and certificate expiry tracking built in.
• Your data stays on your disk. For some people that is the entire argument, and it is a good one.

None of that is faint praise. If your monitoring needs are internal and you enjoy running your own infrastructure, Uptime Kuma is very hard to beat, and this page is not going to pretend otherwise.

The structural gap: Kuma cannot report its own outage

Here is the failure mode that no amount of Kuma configuration fixes. Your monitoring instance runs on the same server, in the same rack, behind the same router and the same internet connection as some or all of the things it watches. When that shared layer fails, Kuma does not send you an alert saying the site is down. Kuma sends you nothing at all, because Kuma is down too.

Silence and health look identical from where you are sitting. That is the whole problem. A monitoring system that goes quiet during the exact event you bought it for is not reporting good news, it is reporting nothing, and you will not find out which until somebody tells you.

• The ISP drops for four hours overnight. Kuma is up, your services are up, but nothing outside can reach either, and no alert leaves the building.
• The Docker host reboots after an update and the Kuma container does not come back. Monitoring is now permanently silent and everything looks fine.
• The Kuma database fills the disk. Checks stop being written. The dashboard still loads.
• Your reverse proxy or DNS breaks. Kuma checks the service over the local network, gets a 200, and reports green while the public internet gets nothing.
• The power goes out. This one needs no elaboration.

That last scenario, the reverse proxy case, is worth dwelling on. Kuma checking a service from inside your own network is not the same test your users run. It skips your public DNS, your certificate, your CDN, your firewall rules, and your ISP. A check that passes from the inside proves the process is alive. It does not prove anybody can reach it.

Angle one: replace Kuma with a hosted monitor

If the appeal of self-hosting has worn off, the swap is straightforward. Undownable runs the same check types you are using in Kuma, from outside your network, with nothing for you to patch, back up, or restart. The free plan covers ten monitors at five minute intervals with a status page and every alert channel, which is more than most Kuma installs are actually using. Pro is a flat price for the whole team, not per monitor and not per seat, which keeps the arithmetic simple as you grow.

You get HTTP and HTTPS checks, keyword matching, JSON API assertions with dot notation into the response body, TCP port checks, ping, DNS records, full SSL certificate validation, and push heartbeats. Alerts go to email, ntfy (including your own self-hosted ntfy server, with access tokens), Telegram, Slack, Discord, or a plain webhook. Every channel is on every plan, free included.

Angle two: keep Kuma, add an outside backstop

This is the setup we actually recommend, and it costs nothing to try. Keep Uptime Kuma exactly as it is. It stays your detailed internal view: every container, every internal port, every LAN-only thing that a hosted service can never see. Then add a small number of external checks that answer one question Kuma is not able to answer, which is whether the whole thing is still reachable and still alive.

You do not need to duplicate your entire Kuma monitor list. Three or four outside checks is usually the right number, and they fit comfortably in the free plan:

• A heartbeat from the Kuma box itself, so silence becomes an alert instead of an absence.
• An HTTP check on your public front door, from outside, through real DNS and a real certificate.
• An SSL certificate check on the same hostname, because expiry is the outage you can see coming and still somehow miss.
• A check on whatever single service hurts most when it is down.

The heartbeat recipe: make Kuma prove it is alive

A push heartbeat inverts the logic. Instead of something checking your Kuma box, your Kuma box calls out on a schedule, and the alert fires when the calls stop. Because the call has to cross your router and your ISP to arrive, a missing heartbeat catches a dead container, a dead host, a dead network, and a dead building, all with one monitor.

Create a heartbeat monitor in Undownable, set the expected interval, and you get a private URL. Then have the Kuma host hit it from cron:

*/5 * * * * curl -fsS --max-time 10 https://undownable.com/ping/your-monitor-id > /dev/null

Better still, make the ping conditional on Kuma actually being healthy rather than just on cron still running. Ask Kuma for its own status first, and only forward the heartbeat if it answers:

*/5 * * * * curl -fsS --max-time 10 http://localhost:3001/ >/dev/null && curl -fsS --max-time 10 https://undownable.com/ping/your-monitor-id >/dev/null

Now the heartbeat means something specific: the machine is powered, the network is up, the route to the outside world works, and Kuma itself is answering. If any link in that chain breaks, the pings stop and you get paged by something that is not on your network. Kuma can also drive this itself with an HTTP notification pointed at the same URL, if you would rather configure it in the UI than in cron.

Side by side

Where Undownable differs

The vantage point is the headline difference, but a few others matter day to day.

• Checks run from outside your infrastructure, so a passing check is evidence a user could have reached you, not just evidence a process is running.
• Alerts are delivered exactly once, tracked in a ledger, so a flapping monitor cannot double-page you at 3am or quietly swallow the recovery notice.
• Confirmation thresholds mean a single blip never pages anybody. A monitor has to fail consecutive checks before it opens an incident.
• There is a degraded state distinct from down, so a certificate with nine days left is visible and alerted without being counted as an outage.
• SSL checks verify the full chain and the hostname, not only the expiry date, and warn on an escalating schedule at 30, 14, 7, and 1 days out.
• Maintenance windows can be opened and closed from your deploy script through the API, so a planned reboot does not page the team.
• Automation is first class: a versioned REST API and an MCP server, both with least-privilege tokens you can pin to a single team.
• Nothing to maintain. No container to update, no database to back up, no disk to fill.

Who should stick with Uptime Kuma

Plenty of people, and we would rather say so than pretend otherwise.

• If most of what you monitor is only reachable from inside your LAN or VPN, an outside-only service cannot see it and Kuma can. Keep Kuma.
• If you need hundreds of monitors and the budget is zero, unlimited-and-free wins on arithmetic alone.
• If your requirements say monitoring data cannot leave your premises, that decision is already made.
• If you need a specific niche notification provider that hosted services do not carry, Kuma almost certainly has it.
• If sub-minute check intervals matter to you, your own hardware will go faster than any tier we sell.

In every one of those cases the recommendation is the same: keep Kuma as your primary, and put one free heartbeat on it so its silence is not mistaken for good health.