Tired of Self-Hosting Uptime Kuma? An Honest Look at the Hosted Path

Let's get one thing straight before anything else: Uptime Kuma is excellent software. It's one of the most polished self-hosted projects in existence, the UI embarrasses plenty of paid products, and the maintainers have earned every one of those GitHub stars. If people move off it, and they do, it's almost never because the software failed them.

It's because of everything around the software. The recurring pains are operational, and they compound quietly:

• The monitor can't monitor itself. When the VPS running Kuma goes down, so does every check on it. You find out your API was offline for four hours from a customer email, and then you discover Kuma was down for six. Who watches the watcher is not a philosophy question here, it's a pager gap.
• One vantage point. Kuma probes from wherever it runs. It cannot distinguish "the site is down" from "my VPS provider is having network weather," because it has no second region to confirm with.
• You are the ops team. Upgrades, Docker image bumps, backups of the SQLite database (and the occasional lock or corruption when the disk fills), TLS renewal on the dashboard, reverse proxy config. None of it is hard. All of it is recurring.
• No incident lifecycle or on-call. Kuma sends notifications. It does not open incidents, escalate to whoever is on call, or track acknowledgment. At 3 a.m., a Telegram message that nobody saw is functionally the same as no alert.
• Notification sprawl. Ninety-plus notification providers is impressive, but each one is fire-and-forget. There is no dedupe, no routing logic, no "only page me if it fails from two places."

If you're weighing tools feature by feature, we keep a full Uptime Kuma alternative comparison that goes monitor type by monitor type. This post is about the decision underneath that: should you be self-hosting your uptime monitoring at all, and if you switch, what do you actually give up?

Self-hosted vs hosted: the honest decision criteria

Most "self-hosted vs hosted uptime monitoring" content is written by someone selling one side. Here's the table we wish had existed when we were on the other side of this decision. The last row matters most, because for most Kuma users the real objection to hosted tools was never money. It was control.

The hosted options, compared

If you decide the hosted column is where you need to be, here's the honest lay of the land for a Kuma refugee, including the option of not leaving at all.

upti.my

Built for exactly this migration path. Every Kuma monitor type you actually use maps to a native check type (mapping table below), checks probe from multiple continents with multi-node confirmation, and incidents have a real lifecycle: open, acknowledge, escalate, resolve. The free plan ($0) covers 10 checks, 5 heartbeats, and 1 public status page, which is a typical homelab-graduated-to-production setup. Starter is $9/mo, Growth is $39/mo with a 14-day trial and adds custom workflows including self-healing, Scale is $99/mo. The differentiator for this audience is heartbeat monitoring for everything behind your firewall, plus workflow automation, both covered in the split section below.

Better Stack

Better Stack is the polished high end: uptime monitoring merged with log management and a strong incident/on-call product. If your team already wants centralized logging and you have the budget for a per-seat, multi-product bill, it's a serious option. For someone leaving Kuma because a VPS was one more thing to manage, its scope can feel like trading one kind of complexity for another.

UptimeRobot

UptimeRobot is the veteran, and its free tier is famous. The trade-offs are check intervals and depth: the free tier probes infrequently, and the features Kuma users take for granted (fast intervals, keyword assertions, decent status pages) sit behind paid tiers that add up. It's a fine landing spot for genuinely casual monitoring, less so if Kuma's one-minute checks were part of why you liked it.

Hyperping

Hyperping is clean, focused uptime and status pages with a design-forward feel that Kuma users tend to appreciate. It covers the core well. What it lacks for this migration is the operational layer around the checks: heartbeat depth and automation beyond notifications.

Or: stay on Kuma, but harden it

Honest option, and for some readers the right one: keep Kuma and fix only its blind spot. Point one external check at Kuma's own/dashboard (a single free hosted check from any vendor, including ours, does it), so a dead watcher pages you. Add a second Kuma instance in another region if single-vantage false positives bite you, cron your SQLite backups off-box, and accept the maintenance line in the table above as the price. If Kuma down was your only pain, this costs you an evening and zero dollars.

The split that works: heartbeats inside, hosted checks outside

Here's the objection that usually keeps self-hosters on Kuma: half of what they monitor isn't reachable from the internet at all. Cron jobs, internal services, a database on a private network. An external probe can't see any of it, and "just expose an endpoint" is exactly the kind of security trade you self-host to avoid.

The answer is to split the job along the line where each side is actually better. The outside view (is the site reachable from Frankfurt, Virginia, and Singapore; is the status page up when your rack isn't) is a job hosted infrastructure does structurally better, because it lives outside your failure domain. The inside view is a job your own systems handle by reporting out, not by letting probes in.

That's heartbeat monitoring, the same dead-man's-switch model as Kuma's push monitors: your job or service pings a unique URL, and the alert fires when the pings stop. All traffic is outbound, so it works from behind firewalls and NAT with zero inbound exposure, no open ports, and nothing new to install, upgrade, or back up. A curl at the end of a script is the entire integration.

# existing job, one line longer: ping on success, alert on silence
0 3 * * * /usr/local/bin/backup.sh && curl -fsS https://app.upti.my/heartbeat/<your-id>

# anything long-running: let its own health check report outward
* * * * * docker inspect -f '{{.State.Health.Status}}' postgres \
  | grep -q healthy && curl -fsS https://app.upti.my/heartbeat/<other-id>

And the self-healing part Kuma never had comes from workflows, not from software on your box. When a check fails or a heartbeat goes silent, a visual workflow can filter and dedupe the signal, wait out a flap, then call a webhook or provider API that restarts or redeploys the service: restart-on-failure automation with guardrails instead of another daemon to patch. You delete the failure mode where your monitoring shares fate with what it monitors, and you add nothing to your maintenance list. Setup details are in the heartbeat documentation and the workflow documentation.

Migration: recreate your Kuma monitors in an afternoon

The good news about Kuma configs is that they're usually simple: a few dozen HTTP monitors, some TCP and ping checks, a handful of push monitors for cron jobs. The mapping is nearly one to one:

Sizing against the free plan: 10 checks, 5 heartbeats, and 1 public status page. If your Kuma instance watches a personal site, an API, a database port, and a few cron jobs, that fits with room left. The full inventory is in what you get with the free plan.

The one piece that doesn't copy over automatically is your status page audience. If people subscribed to your Kuma status page, publish the new public status page first, announce the URL on the old one, and run both for a couple of weeks before retiring Kuma's. Subscribers re-subscribe; bookmarks take longer, so a redirect from the old status page URL is worth the five minutes of nginx config (your last one, if all goes well).

The cost question, honestly

The strongest argument for staying is real: the VPS you already have makes Kuma genuinely near-free. If you're a hobbyist with one box, no on-call rotation, and nobody downstream of your uptime, staying on Kuma (hardened with that one external check) is the right call, and no honest vendor should tell you otherwise.

The switch case is production stakes. When a false alarm wakes a human, single-vantage probing is expensive. When a real outage goes unnoticed because the watcher died with the watched, that's the most expensive monitoring bill you'll ever pay, it just doesn't arrive as an invoice. Multi-region confirmation, escalation to whoever is on call, and a status page that stays up when your infra doesn't: that's what the $0 to $9/mo actually buys, plus the 1-3 hours a month you stop spending on somebody else's upgrade notes. Where monitoring fits in the bigger picture is covered in how to build a reliability stack, and the wider tool landscape lives on the alternatives overview.

You liked Kuma because it respected you: your hardware, your rules, nothing exposed that didn't need to be. The hosted path can respect the same instincts: it moves the eyes outside your failure domain and lets everything private keep reporting outward. Recreate your Kuma monitors on the free plan this afternoon, run both for a week, and let the results decide.