Uptime Kuma vs Better Stack: Who Watches Your Services When the Box Is the Outage

The first time Uptime Kuma failed me, it did not throw an error. It just went quiet. The mini PC in the hall closet lost power during a storm, the UPS ran out about forty minutes later, and every monitor I had carefully configured stopped checking anything at the exact moment I needed it to. My phone stayed dark. I found out the next morning when my partner asked why the photo backup app was complaining.

That night is the whole comparison in miniature. Uptime Kuma is a superb monitoring tool that lives wherever you put it. Better Stack is a hosted monitoring and incident platform that lives somewhere you do not control and cannot trip over. Which one you want depends less on the feature list and more on a simpler question: when something breaks, where is the watcher standing?

I have run both for the same set of services: a handful of self-hosted apps behind a reverse proxy, a small client website on a VPS, and a couple of cron jobs that should report in every night. Here is what each one actually does well, what it costs you in money and attention, and how I ended up splitting the work.

What each tool is, in one paragraph

Uptime Kuma is an open-source, self-hosted monitor. You run it in a single Docker container, open a web UI, and add checks: HTTP and keyword checks, TCP ports, ping, DNS, Docker container status, and push monitors that wait for a job to call in. It sends notifications through a very long list of providers, from email and Telegram to ntfy, Pushover, Discord, and generic webhooks. It has status pages and maintenance windows. It costs nothing except the machine it runs on and your time.

Better Stack (the product that grew out of Better Uptime and Logtail) is a hosted SaaS. It does uptime checks from multiple regions, heartbeat monitoring for cron jobs, status pages, and, crucially, incident management: on-call schedules, escalation policies, acknowledgements, and phone-call or SMS alerts. It also sells log management and other observability pieces, but for this comparison the uptime and incident side is what matters. There is a free tier that is genuinely usable for small setups, and paid plans that are priced mostly per responder rather than per monitor.

On paper they overlap heavily. In practice they answer different questions.

The vantage point problem

A monitor can only report what it can see from where it stands. That sounds obvious until you notice how often homelab monitoring is standing inside the thing it watches.

If Uptime Kuma runs on the same box as your apps, it can tell you when a container crashes or a port stops answering. It cannot tell you when the box itself is off, when your ISP drops you, when the router reboots into a bad config, or when your dynamic DNS record points at yesterday’s IP address. In each of those cases, Kuma is either dead or blind, and the result looks identical from your phone: silence.

Better Stack checks from outside. Its probes hit your public endpoints from several regions and typically confirm a failure from more than one location before paging you. That confirmation step matters more than it sounds. A single-location checker will occasionally flag a transient routing hiccup between one data center and your house; multi-region confirmation filters most of that noise out. When Better Stack says your site is down, it usually means the internet at large cannot reach it.

The flip side is that Better Stack sees only what is exposed. Your Home Assistant instance on a private VLAN, the NAS web UI, the database port you rightly never forwarded: none of that is visible to a hosted prober unless you punch holes or run some kind of agent. Kuma, sitting on your LAN, can poke all of it.

So the honest summary is: Kuma sees inside, Better Stack sees from outside. Neither sees everything.

Where Uptime Kuma wins

Private services. This is the big one. If most of what you care about lives on your LAN or a tailnet, Kuma is the right tool, full stop. It can check an internal hostname, a Docker container’s health, a Samba port, or a keyword on a dashboard page that never leaves your network.

Check frequency and volume. Kuma lets you check as often as every 20 seconds, on as many monitors as your hardware tolerates. I have around sixty monitors on a modest machine and it barely notices. Hosted free tiers limit both the number of monitors and how often they run; Better Stack’s free plan checks every few minutes, which is fine for a blog and not fine if you want to know within half a minute that your reverse proxy died.

Notification choice. Kuma’s notification list is absurd in the best way. If there is a chat app, push service, or webhook format you like, it is probably there. You can send different monitors to different places, which is handy when family-facing services should buzz one phone and the tinkering stack should only post to a quiet channel.

No account, no data leaving the house. Some people care about this more than others. Kuma does not need to know your hostnames exist, and neither does anyone else.

Cost. Zero, plus whatever the host costs. If you already have a box running 24/7, the marginal cost of Kuma is effectively nothing.

Where Better Stack wins

It survives your outage. The storm night would have been a phone call with Better Stack. The monitor is not in your closet, not on your UPS, and not behind your ISP. For anything public-facing, that independence is the entire point.

Paging that actually wakes you. A push notification is a suggestion. A phone call at 3 a.m. with an escalation to a second person if you do not acknowledge in five minutes is a system. Better Stack’s incident side lets you build on-call rotations, escalation chains, and acknowledgement flows. Kuma can send an alert to a lot of places, but it has no concept of “Omar has not responded, now call Sam.” If more than one person shares responsibility for anything, this feature alone can decide the question.

Incident history and status pages people trust. Kuma has status pages, and they are fine. Better Stack’s status pages are polished, can sit on your own domain on paid plans, support subscriber notifications, and are hosted independently of your infrastructure. A status page hosted on the server that is down is a status page that also says nothing. For a client site or a small SaaS, customers expect the page to load when the product does not.

Less maintenance. Kuma is simple, but it is still software you run: updates, backups of its database, a major-version migration every so often. Better Stack is one more login and zero containers.

Heartbeats with a clean outside view. Both tools support push-style checks for cron jobs. The difference is again vantage: a heartbeat that reports to Better Stack still works when your home server is off, which is exactly when you want to know the nightly backup did not run.

The money, honestly

Uptime Kuma is free software. The real costs are the host and your time. On a machine you already run, that is a few minutes a month for updates and the occasional look at the dashboard. If you give Kuma its own small VPS so it can watch from outside, figure a few dollars a month.

Better Stack’s free tier covers a small number of monitors and heartbeats at a slower check interval, one status page, and email, Slack, and app notifications. For a personal site and a few cron jobs, that can be enough indefinitely. Paid plans are structured around responders, meaning the people who can be paged, with add-ons for extra monitors, faster checks, and phone or SMS alerts. At the time of writing, one responder on a paid plan runs in the neighborhood of a couple of dozen dollars a month, and that is before extras. Check the current pricing page; SaaS pricing drifts, and I would rather you trust their number than mine.

The useful framing is not “free versus paid.” It is “what does a missed outage cost?” For a hobby stack, a missed outage costs you mild embarrassment and a slow Sunday. For a client site with an SLA, one missed night can cost more than a year of a hosted monitor. Price the tool against the failure, not against zero.

Failure modes I have actually hit

Every monitoring setup fails eventually. The useful question is how it fails and whether you find out.

Kuma’s failures are silent. Power loss, a full disk that stops SQLite from writing, a container that did not come back after an update, a notification provider token that expired months ago. In each case the symptom is the same: nothing happens. The dashboard might even still look green if you open it from a cached tab. The fix is to monitor the monitor, which is where a lot of homelab setups quietly get recursive. If the host itself is your worry, the usual answer is to stop asking one machine to watch itself, which is the whole argument for running a second Uptime Kuma somewhere the first one cannot take down with it.

Better Stack’s failures are noisy or blind. Noisy: a flaky upstream, a Cloudflare challenge page that suddenly returns a 403 to the prober, or a keyword check that breaks when you change a page title. Blind: anything not exposed to the internet, and anything that returns 200 while the app underneath is broken. A login page that loads perfectly while the database behind it is gone will pass a basic HTTP check from anywhere in the world. Use keyword or JSON assertions against an endpoint that genuinely touches the backend.

Both fail when the alert path is broken. A monitor that detects a problem and sends an alert to a channel nobody reads is not a monitor. Test the notification end to end. Pause a service on purpose and make sure your phone actually makes noise. I do this every few months, and about one time in four something in the chain has rotted.

How I split the work

After a couple of years of running both, my setup looks like this:

• Uptime Kuma on the LAN watches everything private: containers, internal web UIs, the NAS, Home Assistant, DNS resolvers, the reverse proxy from the inside. Alerts go to my phone as normal-priority push notifications. If this box dies, I lose visibility into internal services, and I have accepted that.
• Better Stack’s free tier watches the handful of things that are public: the reverse proxy’s public hostname, the client site, and a heartbeat for the nightly off-site backup job. If my house goes offline, this is what tells me.
• One external check of the home connection itself. A single Better Stack monitor against a public endpoint served from the house. If it fails, I know the problem is power, ISP, or router, and I stop staring at container logs.

That arrangement costs me nothing extra and covers both blind spots. If I were running a paid product or shared on-call with anyone, I would move the public checks to a paid Better Stack plan for escalations and phone calls, and keep Kuma exactly where it is.

Which one should you pick?

Pick Uptime Kuma alone if nearly everything you run is private, you are the only person who cares when it breaks, and you can live with finding out about a whole-box outage the next morning. It is the best free internal monitor I know of.

Pick Better Stack alone if what you care about is public-facing, you want someone paged reliably when it goes down, and you would rather not maintain monitoring infrastructure. It is especially compelling once more than one person shares responsibility.

Pick both if you have a mix, which, for most people with a homelab and one or two public things, is the actual situation. Let Kuma see inside and let Better Stack stand outside. The overlap is small, the combined cost can be zero, and the storm night stops being a surprise.

The mistake is not choosing the wrong tool. The mistake is putting your only watcher in the same closet, on the same power, behind the same modem as everything it is supposed to watch, and then treating silence as good news.