ntfy vs Pushover vs Gotify: Which Homelab Alert Path Still Wakes You

Uptime Kuma is green until it is not. Healthchecks misses a ping. A disk crosses 90 percent. None of that matters if the path from the script to your pillow is a best-effort banner that iOS batched until morning. Homelab alerting is not a dashboard problem. It is a notification problem: which stack still makes a sound when the house is asleep and the WAN is weird.

ntfy, Pushover, and Gotify all claim to be that stack. I have run all three in front of the same Kuma instance. The winner is not the one with the nicest curl one-liner. It is the one whose failure mode you notice before the NAS does.

What you are actually buying

Pushover is a paid push product. You give them an API token. They give you an app that, in my experience, still treats emergency priority like a real interrupt. You are buying someone else’s APNs and FCM relationship, a priority field that has meaning, and a monthly quota that is annoying only if you page yourself for every container restart.

ntfy is a pub/sub topic you can curl. The public server is free and crowded. Self-hosted ntfy is a container, a name, and a decision about who can publish. The Android story is strong. The iOS story is “it works until Apple’s push path or your server does not.” UnifiedPush and self-hosted ntfy are a lifestyle. The lifestyle is why people switch. It is also why a relative’s iPhone stays silent.

Gotify is a self-hosted server plus official apps. It is closer to “my Pushover at home.” It does not pretend to be a public topic bus. You operate the server. When the server is on the same UPS as the NAS you are alerting about, you have built a joke. People build that joke constantly.

All three can look identical in a Saturday test: you curl, the phone buzzes, you smile. The 3 a.m. test is different. Priority, background restrictions, and whether the alert server shares fate with the dying host are the whole product.

The failures that look like “alerting is fine”

The alert host is the down host. Gotify or ntfy on the same Pi as the stack you monitor will not page you when that Pi locks up. Pushover still can, if the probe that fires lives elsewhere — a VPS Healthchecks, a friend’s Kuma, a cron on a travel VPS. Self-host the probes or the notifier off-box. Preferably both. I keep Kuma at home and a single Healthchecks check on a $4 VPS that curls ntfy on a public topic I rotate. When the house dies, the VPS still yells.

Priority is decorative. Default ntfy messages are easy to miss in a Focus mode. Pushover’s emergency priority with retry is the one that has actually woken me. Gotify’s priorities exist and then collide with whatever Android decided about battery. If the alert is “sump pump” or “freezer,” test at 1 a.m. with Focus on. If you will not do that test, you do not have a critical path. You have a chat app.

iOS background. Self-hosted push on iPhone is a negotiation with Apple. ntfy’s hosted path and Pushover’s official app lose less often than a Gotify install you sideload in your head. If the household phones are iPhones, do not pick a stack because a Reddit Android user said UnifiedPush is enough. Ask who will debug APNs when the cert on your ntfy box expires.

Topic as password. Public ntfy topics are guessable if you use homelab or your last name. Then you get spam, or you leak disk-full messages to strangers. Access tokens, ACLs, and a boring random topic name are not optional on the public server. On a private server they are still how you keep a guest from publishing “WAKE UP” at scale.

Pushover: the one that still wakes me

I pay Pushover for the alerts I am willing to get out of bed for: water, heat, the one host that means the cameras are gone, a Healthchecks miss on the offsite ping. The app is ugly. The quota is real if you notify on every compose event. The emergency priority with a repeating sound is the feature. Homelab people underrate paying for a push vendor because self-hosting is the identity. Identity does not empty a sump.

What you lose is philosophy and a dependency on their service. If Pushover is down, you are quiet. That has happened less often than my own ntfy certificate has expired. I treat Pushover as the last mile for a handful of checks, not as a syslog.

What you must not do is send every Kuma blip as emergency. You will disable sound by Thursday. Two tiers: a group for noise you read at breakfast, emergency for the four things that flood. If you cannot name the four things, you are not ready for Pushover. You are ready for a Discord webhook you will mute.

ntfy: the one that fits the homelab brain

curl, MQTT-shaped thinking, tags, actions, a web UI. ntfy is how you wire a random script in thirty seconds. Self-hosted, it is also how you keep message bodies off a vendor. That is a real win for a vault alert or a login notice.

The Android app plus a self-hosted server is the happy path. Attachments, click actions, and priorities work well enough that I use ntfy for the noisy middle: container restarts, backup finished, cert bot renewed. I do not use public ntfy for anything I would be ashamed to see on a wall.

The unhappy path is iOS plus self-hosted plus a Focus mode plus a dead WAN. ntfy cannot invent a path to Apple if your house is offline and you did not put ntfy on a VPS. If the phone must ring when the house is dark, the ntfy server cannot live only on the house. People skip that sentence and then write that ntfy is unreliable. The server was in the blast radius.

Rate limits on ntfy.sh exist so you do not treat it like localhost. Burst a backup log at it and you will learn. Self-host if you are chatty. Chatty plus public is how you get blocked and think the disk alert “never fired.”

Gotify: the one that dies with the rack

Gotify is clean if you want a private Pushover-shaped server and you will put it on a host that is not the thing you monitor. A VPS Gotify plus home Kuma is a coherent design. A Gotify add-on on the same Home Assistant yellow that also runs the Zigbee stick is a single point of silence.

The apps work. The feature set is smaller than ntfy. The operations are yours: TLS, backups of the database, client tokens, upgrades. If you already operate Vaultwarden, you can operate Gotify. If you wanted “no vendors” and you only have one box, you wanted a contradiction.

I would pick Gotify over ntfy when I want a closed user list and I do not need public topics or ntfy’s extras. I would pick ntfy over Gotify when I want the ecosystem and the curl culture. I would pick neither as the only 3 a.m. path if they share a UPS with the failure.

A wiring that has actually woken me

Four emergency checks: water leak, freezer temp, offsite Healthchecks miss, and “the subnet router is gone.” Those go to Pushover emergency. They are probed from a VPS when the failure could be the house.

Everything else goes to self-hosted ntfy on a small VPS, not on the NAS. Kuma, backup scripts, cert renewals. Android phones subscribe. iPhones either use ntfy’s hosted gateway story you have tested or they get Pushover for the middle tier too. I do not run Gotify unless I am already off the ntfy extras and I want a simpler server. One notifier family is enough. Two is a debug tax.

Home Assistant notify is not a third vendor if it just calls these. It is a third vendor if you rely on the companion app’s cloud. Test the companion app in airplane mode and in Focus. Then decide whether you trust it for water. I do not.

Mute rules matter more than the logo. A backup that finishes every night should not make a sound. A backup that did not finish should. People send success to the same channel as failure and then disable the channel. Split them.

How to test without flooding the family

Pick one phone. Enable the Focus mode you actually sleep with. Have a VPS curl the emergency path at 1 a.m. once. If you sleep through it, the stack failed. If a partner wakes angry, the stack worked and your social SLA needs a quiet hours rule for non-water alerts.

Unplug the home notifier host and fire a house-down probe from outside. If nothing arrives, you notified yourself from inside the fire.

Expire a certificate on a staging ntfy and watch the app. If the app fails closed without a fallback, you need a second path or a monitor on the notifier itself — from a different place.

The close

Pushover still wins the alerts that must interrupt sleep, because priority and someone else’s push path are the product. ntfy wins the homelab middle if the server does not live on the dying NAS. Gotify wins only as a private server you placed off the blast radius.

The dashboard can be perfect. The path to the pillow is the system. If that path shares a power strip with the disk you care about, you will sleep through the interesting night. Move the notifier, pay for the last mile if you have to, and test at 1 a.m. like you mean it.