ntfy on the Same Box as Kuma: The Alert Path That Dies With the Outage

Uptime Kuma turns red. ntfy is supposed to make the phone buzz. Both containers sit on the same mini PC, behind the same switch, on the same UPS. The outage that takes down the monitored host also takes down the messenger. Your dashboard is honest. Your pocket is silent. That is not bad luck. That is topology.

Self-hosting ntfy next to Kuma is popular because it is tidy: one Compose file, one backup job, one box to love. It is also how alert paths inherit every failure domain you were trying to notice. The decision is not “ntfy versus Pushover.” It is whether the notifier is allowed to die in the same incident as the thing it watches.

If you only remember one ops rule for homelab alerting: the path that tells you the lab is down must not live only in the lab.

What “same box” really couples

Co-locating Kuma and ntfy couples more than disk:

• power loss and UPS exhaustion
• kernel panics and storage death
• Docker daemon hangs
• NIC or switch failures on that segment
• “I upgraded Compose and the whole stack stayed down”
• WAN outages that also block outbound pushes if your path needs the internet—but that is a different failure, and it still hurts when the notifier is local-only to a dead LAN

Kuma can be perfect at detecting that Nginx died on another VM. It cannot notify you through an ntfy that lost the same power strip.

When same-box ntfy is still acceptable

Keep ntfy beside Kuma when the alerts are not life-or-lab:

• you mostly want push for “backup finished” and “cert renews soon”
• you are physically near the lab and will notice heat/silence anyway
• you have a second path (email via an external provider, SMS, healthchecks.io ping) for host-down events
• you are prototyping and will move the notifier later on purpose

Same-box is a staging topology. It becomes malpractice when it is the only page-out for “the house gateway is offline while we are away.”

The failure you actually care about

Sort alerts into classes:

1. App unhealthy, host fine — local ntfy is fine. Kuma and ntfy still run; the monitored container is the patient.
2. Host unhealthy, network fine — local ntfy dies with the host. You need an external watcher or an external notifier.
3. Network/WAN unhealthy — neither local Kuma/ntfy nor a VPS that cannot reach you may save you; think about cellular paths, or accept that remote WAN loss is invisible until you get home.

Most people install Kuma because of class 2. Then they leave the notifier in class 2’s blast radius. That is the bug.

Notification noise versus outage signal

Remote ntfy does not excuse spamming yourself. If every cert warning pages like a house fire, you will mute the app and recreate silence socially instead of topologically. Severity tags, quiet hours, and separate topics for “info” versus “page” matter more once the pipe is reliable.

A reliable pipe with bad triage still fails. Fix topology first, then taste.

Split the planes: monitor local, notify elsewhere

A pattern that works for solo operators:

• Kuma stays in the lab (or you run two Kumás—see below)
• ntfy (or Pushover/Gotify SaaS) lives on a cheap VPS, a friend’s box, or a hosted push service
• Kuma’s notification outbound goes to that remote endpoint

Now a lab power cut can still send “Kuma unreachable” if you also have an external check—or at least, when Kuma is up and a service dies, push still works because ntfy did not share the UPS.

Omar’s hard-earned version of this lesson is blunt: paying for Pushover, then self-hosting ntfy on the same UPS as the NAS, recreates the silence. Put the notifier on purpose somewhere else.

Two monitors beat one clever box

Even with remote ntfy, a dead Kuma host leaves a gap: nothing is watching the watcher. Options:

• a second Kuma or Healthchecks-style heartbeat from the lab to an external check
• a simple external uptime ping against a canary URL on the lab edge
• Healthchecks.io / a cron heartbeat that fails when the lab scheduler dies

You do not need enterprise observability. You need one dependency arrow that points outward for “lab is dark.”

Same Compose file, different hosts

“But I want one Compose.” Keep the compose definitions; change the deploy target. Run `ntfy` as a service on a $4–$6 VPS with a locked-down reverse proxy and auth. Point Kuma at it. Back up both places. The aesthetic of one YAML does not require one motherboard.

If you refuse a VPS, put ntfy on a different physical failure domain in the house: alternate UPS, alternate Pi on a different outlet circuit, alternate upstream if you can. Same rack shelf is not a different domain.

Authentication and accidental public ntfy

Moving ntfy to a VPS tempts a wide-open topic URL. Do not. Use auth, ACLs, HTTPS, and topics that are not guessable. A public ntfy instance that accepts anyone’s messages is how you get spam and spoofed “alerts.”

Also decide whether phones talk to ntfy directly on the VPS or through a tunnel. Direct HTTPS with good auth is usually calmer than exposing random ports.

Email is not cheating

If a VPS feels like too many moving parts, an external email notification from Kuma still beats a local-only push server for host-down events—provided the mail path does not also route through the dead lab’s SMTP relay. Use a real external provider. Local Postfix on the NAS is another same-fate trap wearing a necktie.

Many solo operators end up hybrid: ntfy for rich mobile pushes on app faults, email or a hosted check for “Kuma itself is gone.” Hybrid is not impurity. Hybrid is admitting failure domains.

What about Gotify or Pushover instead?

The topology rule is vendor-agnostic. Pushover on phones with Kuma in the lab already splits the notify plane to a hosted service—that is why it feels more reliable during home outages (until your phone has no data). Gotify self-hosted beside Kuma recreates the same-box problem. Move the push server, or do not self-host the push server.

Choose the push product for client UX and cost. Choose its home for survival.

Testing the silence

Prove the topology:

1. Stop the monitored service — phone should buzz.
2. Stop ntfy only — you should notice missing heartbeats or a secondary path.
3. Stop the Kuma host (or pull its network) — something external should notice within your agreed SLA, even if that SLA is “email in five minutes.”
4. Pull the UPS load for a planned test once a year if you can do it safely.

If step 3 is silent, you do not have host-down alerting. You have app-down alerting with optimistic infrastructure.

Chooser

• Hobby metrics, on-site human: same-box ntfy is tolerable.
• Travel, family relying on VPN/home services: remote notifier required.
• Already paying for Pushover/OneSignal/etc.: use it for class-2 events; self-host ntfy for class-1 noise if you want.
• Want fully self-hosted: self-host ntfy off-site, not beside Kuma.

ntfy beside Kuma is neat Compose. It is also a shared fate. Alerts that matter deserve a path that can scream while the lab is dead—not a push server waiting for the same power brick to return.

Tidy stacks are for apps. Alerting is allowed to be slightly ugly if the ugly part survives the fire. Put ntfy where the outage is not, test the quiet failure once, and let Kuma go red without taking your phone down with it.

If your current Compose file shows `kuma` and `ntfy` on one networks block and one volume drive, treat that as a smell for anything you would wake up for. Keep them together for toys. Split them for truth. The dashboard can stay pretty either way—the phone is the part that has to work when the dashboard cannot load.