Comparison
Uptime Kuma cannot page you about Uptime Kuma.
That is not a criticism of it. It is the one failure a self-hosted monitor is structurally unable to cover, and it is the failure a pager on your phone is for.
- Keep Uptime Kuma. It is doing work Nightbell cannot.
- It watches while your phone is off, it holds the history, it has status pages and maintenance windows, and it fans out to dozens of notification services. Nothing here is an argument for turning it off.
- Add Nightbell as the thing that makes the noise.
- No machine to keep alive, no certificate to renew, and an alarm that loops on a channel that bypasses Do Not Disturb. Point it at your Kuma instance and the one outage your monitoring cannot report becomes the one it shouts about.
Two tools that overlap on the word monitoring and almost nowhere else.
Structural rows only. None of this changes when either project ships a release.
- What you have to run
- NightbellNothing. It is an APK.
- Uptime KumaA machine, a container, a certificate, and updates for all three.
- While your phone is off
- NightbellNot watching. That is the cost of having no server.
- Uptime KumaStill watching.
- Reaching you
- NightbellNo delivery step for the alarm: it is already on the device. Webhooks too, if you want them.
- Uptime KumaA notification provider, a webhook, or an app in the middle.
- At 3am you get
- NightbellThe whole screen in red and an alarm looping until acknowledged.
- Uptime KumaWhatever your provider delivered, however your phone decided to show it.
- Status page
- NightbellNone.
- Uptime KumaYes, and other people can read it.
- Who watches it
- NightbellDifferent device, different network, so it can watch the box.
- Uptime KumaNothing on the same box, by definition.
- Setup cost
- NightbellFour permission grants and a URL.
- Uptime KumaAn evening, then ongoing maintenance.
The outage your monitoring cannot report is the one it is having.
Every self-hosted monitor has the same hole in it, and it is not a bug anybody can fix. The component that notices a failure and the component that tells you about it are on the same machine. When that machine reboots into a broken certificate, fills its disk, or comes back up with the container stopped, nothing is noticed and therefore nothing is sent. The dashboard is not red. The dashboard is not there.
What that looks like in practice is a quiet night. No alerts is indistinguishable from everything being fine, which is exactly why it goes on for hours, and it is usually a customer who ends it.
A phone closes it because a phone is somewhere else. Different device, different network, different power supply, nothing shared with the box except the thing being watched. Point one status check at your instance, set the alert to urgent, and the failure that used to be silence becomes the loudest thing in the room.
One monitor, and the settings that make it worth having.
Add a status check pointing at your instance over the address you would actually reach it on from outside the house, not the LAN one. A monitor on a LAN address stops passing the moment you leave, which is a true fact about your network rather than a bug, and it is the easiest way to build this setup wrong.
Set the alert to urgent so it takes the whole screen rather than arriving as a notification, and grant Do Not Disturb access so it is allowed to make noise at the hour you need it to. Urgent is on the monitor's cadence step, Do Not Disturb access is in the pager setup screen, and neither is on by default, because an app that gave itself permission to override your phone's silent mode without being asked would deserve the review it got.
Leave the cadence on the default. Fifteen minutes is Android's floor for background work and it is the right interval for this particular monitor: you are watching for a host that has gone away entirely, not for a slow response, and strict mode's permanent notification is not worth spending on a check that would catch the outage on its next pass anyway.