Push a confirmed outage
The message goes out once enough independent EU locations fail the check often enough in a row, not on the first failed request; both thresholds sit in your package.
Use Uptimeify with ntfy.
One topic URL, on ntfy.sh or on the server you run yourself, and every confirmed outage arrives as a push without an account anywhere.
What lands in ntfy
Everything the alert pipeline sends to ntfy is on this list, and nothing beyond it. Read it once and you know what your team will see.
Push the recovery
The all clear arrives on the same topic, at a lower priority, because it is news and not an emergency.
Set priority per event
An outage arrives at ntfy's max priority, a warning at high and a recovery at default, so your phone can treat them differently.
Tag the message
Every push carries a tag that turns into an icon in the app, a rotating light for an outage and a check mark for a recovery.
Keep the body plain
The message is plain text, so it reads the same in the app, in a browser and in whatever else subscribes to the topic.
Reach your own server
ntfy.sh and a server you host yourself both work, and the address is checked against internal targets before it is called.
Authenticate when the topic is protected
An access token is sent as a bearer header when you set one, so a private topic works as well as a public one.
Warn before certificates and domains expire
Expiring TLS certificates, expiring domains and blocklist hits reach the same topic.
A topic per monitor
Each channel is its own topic URL, so a client's outage reaches the people who look after that client instead of everyone.
Send a test message
The dashboard sends a test push to the topic while you set it up, so a wrong topic or token is caught before the first real alert.
Teams that run their monitoring on Uptimeify
Minutes to set up. Then it runs on its own.
1. Pick a topic
Choose a topic name on ntfy.sh or on your own server and subscribe to it in the app.
Topic URL
ntfy.sh/uptimeify-alertsStored encrypted
2. Take the topic URL
The topic URL is the whole destination, and an access token is only needed if the topic is protected.
3. Paste it into Uptimeify
Add the URL as an ntfy channel, assign the monitors it covers, and send the test push.
Before you connect ntfy.
No. A topic name is enough on ntfy.sh, and on your own server it is whatever you decided. An access token is only needed when the topic is protected.
Yes. The address is resolved and checked against internal and loopback targets before a request is sent, so a topic URL cannot be pointed at something inside your network.
By priority and tag. An outage arrives at max priority with a rotating light, a warning at high, and a recovery at default with a check mark.
No. Your quota covers monitors and the monthly SMS and voice allowance. Alerts over ntfy, email, webhook or Slack do not draw on it.
Yes. Every channel is its own topic URL, and you assign monitors and clients to it. A client's outage then reaches the people who look after that client, not everyone.
Every alert, where your team already works.
Connect ntfy once, and every confirmed outage arrives on the topic you already subscribe to.