Uptime Kuma + ntfy: When the Dashboard Is Green and Your Phone Stays Dark

Uptime Kuma is green. The HTTP check returned 200. The Docker host is up because you are looking at it. Your phone did not make a sound last night when the same host was not up for fourteen minutes. You open ntfy, or you do not, because the topic never got a message, or the message arrived as a silent tile you swiped away at breakfast. The dashboard did its job. The notifier did not page a human. Those are different products sharing a screenshot.

I have paid for Pushover, self-hosted ntfy on the same UPS as the NAS, and then moved the notifier to a VPS on purpose. The move was not ideology. It was the night Kuma and ntfy died together and the only green I had was the last cached tab on my laptop. If you wired Kuma to ntfy and you sleep through outages, you probably built that night’s architecture and have not noticed yet.

What people think they installed

Kuma is a checker with a pretty status page. It polls URLs, pings, keywords, Docker containers, and push heartbeats. When a check fails, it fires a notification provider: Telegram, Discord, email, Gotify, Pushover, ntfy, a webhook. The UI makes this look like a solved last mile. You paste an ntfy topic URL, you send a test, the phone buzzes, you close the laptop.

ntfy is a pub/sub that happens to have a good Android and iOS app. You publish to a topic. Subscribers get a push. Self-hosted, it is a binary or a container and a bit of reverse proxy. Hosted ntfy.sh is the demo that becomes production because the test worked.

The join is a URL in Kuma. That is the entire integration. There is no shared health between them. Kuma does not know if the phone still has the topic open. ntfy does not know if Kuma is lying about “up.” Green on one side is not a delivery receipt on the other.

The failure I keep seeing: same power domain

Kuma on the NUC. ntfy on the NUC. The NUC on the same UPS as the router, or on no UPS. The house loses power, or the Docker disk fills, or you compose down for an upgrade. Both processes die. There is no message, because the messenger died in the same second as the checker. In the morning the dashboard is green again — you started the stack — and you have no record that anything happened except a clock on the UPS if you have one.

This is the setup I will not run anymore. The notifier has to live somewhere that can still speak when the homelab is the incident. A $5 VPS, or ntfy.sh if you can stand the hosted topic, or Pushover if you want a company whose only job is the buzz. I still self-host ntfy. I self-host it on a VPS that is not in the basement. The basement can go dark. The phone should not.

People object that the VPS is another thing to monitor. Yes. Monitor the VPS from a third place, or accept that you have one remaining dependency. Two boxes in one rack is not two dependencies. It is a costume.

The failure that looks like ntfy: Kuma never fired

Retries and grace periods are how Kuma avoids flapping. They are also how a fourteen-minute blip never becomes a notification. You set three retries at sixty seconds because the cable modem is rude. The outage was two minutes. The dashboard shows a tiny dip if you squint at the chart. The phone stayed dark because, correctly, the monitor decided it was not an incident.

Maintenance windows do the same. You put Kuma in maintenance so you can reboot. You forget to take it out. For a week the page is a calm green or a polite pause and you are not being paged because you asked not to be. I have done this. The shame is specific.

Push monitors — the kind where a cron job must check in — fail the other way. The job dies, Kuma should go red, ntfy should fire. If the push monitor is misconfigured, or the grace is a day, or you pointed the cron at a different Kuma, the dashboard stays green. ntfy is innocent. You will still search “ntfy not working.”

The failure that is ntfy: the phone never subscribed

iOS especially. The ntfy app needs a topic, a server URL if you self-host, and permission to actually alert. After an iOS update, notification permission can reset. Focus can eat the banner. Low Power Mode can delay background refresh so the app is not connected when the message is published. Instant delivery on iOS is a known fight: you want a foreground connection or a provider that uses APNs correctly. Self-hosted ntfy behind a clever proxy can break the path the app uses to stay awake.

Android is kinder and then it is not. Battery optimization on a Pixel or a Samsung will freeze the ntfy app overnight. The message is on the server. The phone fetches it when you open the app at 8:10. You were not paged. You pulled.

Topics are another quiet hole. Kuma publishes to https://ntfy.example.com/homelab. The phone is subscribed to Homelab or to the ntfy.sh topic you used in the first test. Test message from Kuma’s button works because you watched it. The 3 a.m. failure uses the same URL you think it does. I now send a scheduled “canary” from a cron on the VPS to the same topic Kuma uses, not a different one. If the canary is late, the phone path is dead even if Kuma is happy.

Priority, tags, and the swipe reflex

ntfy can set priority, tags, and click URLs. Kuma can pass some of that if you use the notification extras. Most people send default priority. Default priority on a phone that already gets mail is a badge, not a wake-up. You will train yourself to ignore it. Then the disk-full alert is the same chime as a blog RSS you should not have routed through the same topic.

Split topics: homelab-crit with max priority and a sound you cannot confuse, homelab-info for “cert renews in 14 days.” Put Kuma’s down/up on crit. Put the weekly digest somewhere else or nowhere. I have paid for Pushover because its emergency priority will keep ringing. ntfy can get close. It will not save you from one topic that means everything.

Do not send Kuma “up” messages to the same urgent channel if your stack flaps. You will disable notifications and then the next down is silent by policy.

A wiring that pages me

This is what I run for households that sleep through dashboards:

• Kuma on the homelab, checks for local services, plus one check that is “can this box reach the VPS ntfy.”
• ntfy on a VPS, TLS, a private topic name that is not alerts, authentication so the topic is not a guestbook.
• Kuma’s ntfy provider pointed at that VPS, high priority for down, no up noise except on the two services I must know recovered.
• A canary cron on a third place — a cheap GitHub Action, a friend’s box, Healthchecks.io pinging a Kuma push monitor — so a dead homelab still produces a message from somewhere that is not the homelab.
• Phone: ntfy exempt from battery optimization, Time Sensitive on iOS, not inside a Focus that eats unknown apps. Test after every OS update, not after the next outage.

If that sounds like more than “paste a URL,” it is. The paste is how you get a green test. The rest is how you get a dark room and a sound.

When I still pay Pushover

I still pay Pushover for two people who will not debug APNs. The receipt is better. The emergency retry is better. ntfy is enough for me because I will maintain the VPS. It is not enough if the only operator is also the only person who mutes unknown notification apps. Be honest about which person you are at 2 a.m.

Gotify is in this conversation for Android-only houses. Same class of problem: self-host on the NAS, die with the NAS. I will not re-litigate the brand. Put the notifier off the failing machine.

The green dashboard is not the pager

Kuma’s job is to notice. ntfy’s job is to interrupt. If they share a host, they share a fate. If they share a topic with junk, they share a mute. If the phone is in a Focus you set up to sleep better, the architecture lost to a moon icon.

I stop trusting a stack when the only proof it works is a test button I pressed while I was looking at the phone. I start trusting it when a canary I did not trigger wakes me, and when a real outage last month is a message I can still find in ntfy, not a story I reconstructed from a green chart.

Wire Kuma to ntfy. Then assume both will lie in different dialects. Put the messenger where the incident is not, give it a priority you cannot swipe in your sleep, and keep a third heartbeat that does not live in the same compose file. The dashboard can stay green. I need the phone to disagree when the house is dark.