Uptime notifications that actually wake you up

Q: What happens if my monitoring tool itself goes down?

Nothing, and that is the problem - a dead monitor is silent. Use a dead man's switch: have the job ping a service like Healthchecks.io on success and alert when the ping stops arriving, rather than relying on a failure being reported.

Every monitoring tool can send an email. The problem isn't detection – it's that the alert arrives in the same channel as a newsletter, with the same sound as a calendar invite. A webhook pointed at your phone fixes the last mile.

Almost every monitor speaks webhook

You don't need a plugin or an integration for any of these – they all have a generic webhook notification type, which means they can all POST to a URL you choose. Create a Webhooky endpoint, copy its URL, paste it in:

Uptime Kuma – the self-hosted favourite. Add a notification of type Webhook and paste the URL. We wrote this one up in detail: Uptime Kuma push notifications.
UptimeRobot – add a web-hook alert contact and point it at the URL.
Better Stack – webhook integration per monitor; see Better Stack alerts.
Healthchecks.io – the dead-man's-switch case, below. Details in Healthchecks.io notifications.
Grafana – a webhook contact point in alerting; see Grafana alerts.
Prometheus Alertmanager – a webhook_config receiver; see Alertmanager notifications.
A bare shell script – one line of curl, no tool needed at all.

Because a Webhooky endpoint accepts any POST body, none of these need their payload reshaped. If the body has no title or message field, the notification falls back to the title, text and sound you configured on the endpoint – so "api.example.com is down" with a siren works without writing a line of code.

The alert that never comes

Uptime monitoring has a blind spot that catches people out: it tells you when a check fails, but not when the check stops running. A cron job that silently stopped being scheduled, a backup script that was never triggered, a monitoring container that died – all of them are quiet. Silence looks exactly like success.

The fix is a dead man's switch: instead of the job telling you it failed, it tells you it succeeded, and something complains when that stops arriving. Healthchecks.io is built for exactly this – your job pings a URL on success, and if the ping doesn't arrive within the window you set, Healthchecks fires its webhook. Point that at your phone and the notification you get is "the nightly backup didn't run", which is the one you actually needed.

If you'd rather not run another service, the poor man's version works too: have the job POST to one Webhooky endpoint on success with a quiet sound, so a missing nightly ping becomes visible in that endpoint's history.

One sound per severity

This is where a dedicated endpoint earns its place over email. Alert fatigue is real, and the cure isn't fewer alerts – it's alerts you can triage without looking:

Down – a siren or buzzer. The only one allowed to be unpleasant.
Recovered – something short and pleasant. Hearing it means you can stop worrying, which matters as much as the first alert.
Degraded / slow – a neutral tone. Worth knowing, not worth waking up for.
Certificate expiring – a quiet one. Thirty days of warning doesn't need a siren.
Backup finished – quietest of all, or no sound at all, just history.

After a week you stop reading these. A siren at 3am means production; a soft chime at 3am means the backup is fine and you can go back to sleep. There are 40 sounds, set per endpoint or overridden per message with the sound field.

Two useful one-liners

Notify when any long-running command finishes, whatever its result:

./long-migration.sh; curl -s -X POST https://api.webhooky.app/YOUR_KEY \
  -d "{\"title\":\"Migration done\",\"message\":\"exit $?\"}"

Or guard a cron job so you hear about failures only:

0 3 * * * /opt/backup.sh || curl -s -X POST https://api.webhooky.app/YOUR_KEY \
  -d '{"title":"❌ Backup failed","sound":"buzzer"}'

More patterns in notify when your script finishes.

Why this beats email and chat for alerting

Email has no urgency gradient – everything arrives in one list with one sound. Slack and Discord are better for a team but worse for being woken up, since their notification settings are global rather than per-alert, and an outage at 3am competes with a channel someone posted a gif in. A dedicated endpoint gives each alert type its own sound and vibration pattern, arrives on all your devices at once, and keeps a per-endpoint history so you can see how often something has been flapping. No account to create – install the app, make an endpoint, paste the URL into your monitor.

Frequently asked questions

How do I get a push notification when my server goes down?

Add a webhook notification in your monitoring tool – Uptime Kuma, UptimeRobot, Better Stack and Grafana all have a generic webhook type – and point it at a URL that notifies you. A Webhooky endpoint turns that POST into a push with its own sound, no server in between.

What happens if my monitoring tool itself goes down?

Nothing, and that's the problem – a dead monitor is silent. Use a dead man's switch: have the job ping a service like Healthchecks.io on success and alert when the ping stops arriving, rather than relying on a failure being reported.

Can I have a different sound for down and recovered?

Yes. Create one endpoint per alert type and assign a sound to each, or override the sound per message with a sound field in the JSON body. Webhooky has 40 sounds.

Does Uptime Kuma need a plugin for push notifications?

No. Uptime Kuma has a generic Webhook notification type built in – add one, paste your endpoint URL and attach it to your monitors.