Send Uptime Kuma Notifications to Your iPhone

Uptime Kuma is the rare self-hosted tool that just works. Twenty monitors, a clean dashboard, checks every sixty seconds, and it has known your site was down since 02:14.

That last part is the catch. It knew. You did not, because the dashboard was in a browser tab on a laptop that was closed. A status page nobody is looking at is a log file with better colours.

Getting it onto your phone takes one URL and no code at all.

Why not the built-in options

Uptime Kuma ships with ninety-odd notification providers, so it is fair to ask why you would add another. Two reasons, and they are both about what happens at 2am.

Telegram and Discord work, but they deliver into a chat app alongside everything else in that app. An outage alert sitting under a group thread is an outage alert you see in the morning. Email is worse: it lands in the same inbox as the newsletters.

The setup below sends a normal iOS notification. It breaks through on the lock screen, it stays there until you deal with it, and it is not competing with anything.

Step 1: Get your app key

Install TheNotificationApp on your iPhone, sign in with Apple, and create an application. Call it Uptime. Tap into it and copy the app_key.

Keep it handy, because it goes into the URL in the next step. It maps to your devices, so anything sent with it reaches your phone and nobody else's.

Step 2: Build the webhook URL

You want the static webhook here. It takes whatever JSON arrives and formats the whole payload into a readable notification body, which is exactly right for Uptime Kuma because its payload is already a sensible summary of what happened.

https://thenotification.app/api/webhook/static/?app_key=YOUR_API_KEY&title=Uptime%20Kuma

Two things to know. app_key is required. title is optional and sets the notification headline, so URL-encode the spaces: Uptime%20Kuma, not Uptime Kuma. Get that wrong and the title silently truncates at the space.

Test it from your terminal before touching Uptime Kuma at all. If this does not buzz your phone, nothing downstream will:

curl -X POST "https://thenotification.app/api/webhook/static/?app_key=YOUR_API_KEY&title=Uptime%20Kuma" \
  -H "Content-Type: application/json" \
  -d '{"monitor":"web-01","status":"down","msg":"504 Gateway Timeout"}'

The full parameter list is in the static webhook docs.

Step 3: Add it as a notification in Uptime Kuma

In Uptime Kuma, go to Settings, then Notifications, then Setup Notification.

• Notification Type: Webhook
• Friendly Name: iPhone
• Post URL: the URL from step 2
• Content Type: application/json

Content type is the field people get wrong. Uptime Kuma offers multipart/form-data as well, and the webhook endpoint expects JSON. Pick the wrong one and you get a notification with an empty body and no obvious reason why.

Tick Default enabled and Apply on all existing monitors before saving. The first means monitors you add next month are covered without you remembering; the second retrofits the twenty you already have. Skipping these is the most common way this ends up half configured.

Hit Test. Your phone should buzz within a second or two.

Step 4: Decide what actually deserves a buzz

Uptime Kuma fires on both down and up by default, which is right. Two notifications per incident, one when it breaks and one when it recovers, is the pattern that lets you go back to sleep.

What ruins it is a flapping monitor. A service that bounces every ninety seconds will send you forty notifications before breakfast and teach you to ignore the channel entirely. Two settings prevent that:

• Retries: set to 2 or 3. Kuma then only marks a monitor down after consecutive failures, which filters out the single blip that recovers on its own.
• Heartbeat Interval: 60 seconds is plenty for most things. Checking every 20 seconds mostly buys you more chances to flap.

For anything genuinely noisy, set Resend Notification if Down X times to 0 so you get told once per incident rather than every cycle it stays broken.

Getting a cleaner notification body

The static webhook formats the entire payload, which for Uptime Kuma includes the monitor, the status, the message and a chunk of heartbeat detail. Readable, but wordier than it needs to be.

If you want just the essentials, switch to the dynamic webhook and name the fields you care about:

https://thenotification.app/api/webhook/dynamic/?app_key=YOUR_API_KEY&title=msg&body=monitor

That pulls msg as the headline and the monitor name as the body. The tradeoff is that you are now depending on Uptime Kuma's payload field names, so a future version that renames a field breaks your notification quietly. The static webhook has no such coupling. Start static, move to dynamic only if the noise actually bothers you. Both are covered in the dynamic webhook docs.

The honest part

The free tier is 100 notifications for the lifetime of the account, not per month. For a stable set of monitors that is a long time, because a healthy month is zero notifications. But an outage sends two, and a genuinely bad week can send twenty, so this is the one use case where the lifetime cap is worth thinking about up front. Pro is $2.99 a month for 1,000, which no realistic monitoring setup will exhaust.

Set the retries. A single flapping monitor left unattended will spend a hundred notifications in a day and there is no undoing that.

Where to go next

If you would rather not run Uptime Kuma at all, the same alert from a plain cron job and ten lines of bash is in getting a server down notification on your phone. And anything else that can fire a webhook can now reach your phone the same way, which is the whole point of the URL you just pasted.

Grab a key at thenotification.app and stop finding out about outages from other people.