KumaAlert/Push notifications

Uptime Kuma push notifications

Every way to get an outage onto your phone — and the one route that survives Silent mode.

What Uptime Kuma can do on its own

Uptime Kuma has no push service of its own. What it has is a long list of notification integrations — ntfy, Pushover, Gotify, Telegram, Discord, Slack, SMTP email, generic webhooks and dozens more — and it fires whichever ones you attach to a monitor when that monitor changes state.

You configure them in one place: Settings → Notifications → Setup Notification. Pick the type, fill in the credentials, tick Default enabled if you want it applied to every new monitor, and save. Then open a monitor and confirm the notification is ticked in its Notifications list — this is the step people miss, and it is the reason a correctly configured notification never fires.

Setting up ntfy, the free route

If you just want outages on your phone for nothing, ntfy is the shortest path. It is open source, it has iOS and Android apps, and you can either use the public ntfy.sh server or self-host your own.

1. Pick a topic name that nobody could guess. On the public server a topic is the only thing protecting your alerts — kuma is readable by the world, kuma-a7f2c9d41b8e is not.
2. In Uptime Kuma: Settings → Notifications → Setup Notification, notification type ntfy.
3. Server URL https://ntfy.sh (or your own), topic as above, priority High or Max for anything you care about.
4. Press Test, then install the ntfy app and subscribe to the same topic.
5. Attach the notification to your monitors.

Self-hosting ntfy with access tokens fixes the guessable-topic problem and keeps the whole path under your control. It is one more container to run, which is the trade.

Why your alert was silent at 3am

This is the question behind most searches for Uptime Kuma push notifications, so it is worth being precise about it.

Every route above — ntfy, Pushover, Telegram, Gotify, Discord, email — delivers an ordinary push notification. On iOS an ordinary push notification obeys the ringer switch, Do Not Disturb and every Focus mode. When your phone is on silent, the alert arrives silently. It is on the Lock Screen in the morning, which is exactly when it is useless.

There are only three things that actually break through on iPhone:

• Time Sensitive notifications, which can pierce some Focus modes but never the ringer switch, and which the user can turn off per app.
• Emergency-priority Pushover, which repeats until acknowledged — loud if the phone is not on silent, still silent if it is.
• Apple Critical Alerts, which sound through Silent mode, Do Not Disturb and every Focus, at their own volume. This is a special entitlement Apple grants app-by-app on request; an app cannot simply switch it on.

If you have slept through an outage, the first two are not the fix. The third is.

Critical Alerts on iPhone

KumaAlert holds the Apple Critical Alerts entitlement. In the app you mark individual monitors as critical — the database, the reverse proxy, whatever genuinely justifies waking you — and only those monitors' DOWN alerts arrive as Critical Alerts. Everything else stays a normal, polite notification. It is opt-in per monitor, with its own volume slider, precisely because an app that shouts about everything gets muted within a week.

The delivery path matters as much as the sound. Alerts reach KumaAlert through an outbound webhook from your Uptime Kuma server to a push relay, which forwards to Apple's push service. Three consequences worth knowing:

• Your Uptime Kuma instance never has to be reachable from the internet. It only needs outbound HTTPS.
• The relay never connects back to your server and does not store its address.
• Alerts do not depend on the app being open, or on your phone being able to reach your LAN.

The webhook is created for you when you add a server in the app, so there is no JSON to hand-write. The setup guide has the full walkthrough, including the case where you would rather add the webhook by hand.

Getting through on Android

Android has no exact equivalent of Critical Alerts, but it has something close and it is under your control rather than the app's. Notification channels carry their own importance, sound and Do Not Disturb behaviour, and you can grant any channel a DND override in system settings.

1. Long-press the app's notification → Settings, or go to Settings → Apps → [app] → Notifications.
2. Open the channel that carries outage alerts and set importance to Urgent so it makes sound and pops on screen.
3. Give that channel a distinct alert sound, so you can tell an outage from a message without looking.
4. In Do Not Disturb → Apps, allow that app (or that channel) to override DND.
5. Turn off battery optimisation for the app, or Android will eventually delay its wakeups.

KumaAlert ships separate channels for down alerts, recovery, maintenance and app updates, so you can make outages loud without the rest of it being loud too. There is more detail on the Android guide.

Alerts you will actually keep switched on

The failure mode for monitoring notifications is not missing them. It is muting them. A flapping monitor on a home connection will send you forty alerts in an evening, and after the second evening you turn the whole app off — and then miss the one that mattered. Three settings do most of the work:

• Retries before alerting. In Uptime Kuma, set a monitor's Retries above zero so a single failed check does not page you. Two retries at 60 seconds turns most transient blips into nothing.
• Severity per monitor. Decide, once, which handful of monitors are allowed to wake you. In KumaAlert that is the critical flag; with ntfy it is separate topics at different priorities.
• Quiet hours and maintenance windows. Planned downtime should not page anybody. Uptime Kuma has maintenance windows built in, and KumaAlert can create and edit them from the phone.

When notifications stop arriving