Using n8n to send notifications from Uptime Kuma

There are so many options for monitoring tools out there, some of the quite pricy and some of the open source and free like Uptime Kuma One thing however that I would like to have is the option to send different types of alerts based on the client and also based on the time when the alert occurs.

I will not cover the installation of uptime kuma here and focus on the n8n part.

The uptime kuma webhook

Let’s get started with the n8n webhook configuration in uptime kuma. Create a webhook in n8n and do not forget to use authentication. You can read about creating a webhook and the authentication part in the Always use authentication post. After doing that, head over to uptime kuma and define your notificaiton webhook.

So far so good, now you will get the notifications in n8n, but that doesn’t really help yet.

Setting up clients

As backend I’m using SeaTable but you can go with airtable, google sheets or whatever suits your needs. I am once again remembering Nadia Privalikhina LinkedIn Post

If you believe AI automation tutorials, the entire world runs on Airtable, Gmail, and Google Calendar.

– Nadia Privalikhina

But for this purpose it’s a sufficient tool. You can of course also opt to use any database you like.

Here I am setting up my notification settings, during what times I want alerts, are the notifications silenced and should a ticket be created, more on the details later. For now let’s look at the Uptime Kuma Group.

The webhook you receive from Uptime Kume looks something like this:

"body": {
  "heartbeat": {
    "monitorID": 29,
    "status": 0,
    "time": "2025-08-29 08:41:03.605",
    "msg": "200 - OK, but value is not equal to expected value, value was: [false]",
    "ping": 66,
    "important": true,
    "duration": 60,
    "timezone": "Europe/Vienna",
    "timezoneOffset": "+02:00",
    "localDateTime": "2025-08-29 10:41:03"
  },
  "monitor": {
    "id": 29,
    "name": "Zammad",
    "description": null,
    "pathName": "demo / Zammad Demo",
    "parent": 1337,
    "childrenIDs": []
...

The part that’s required here is the "parent": 1337, this is the group ID in Uptime Kuma which can be used to find the notification configuration for that client.

The Workflow

The workflow itself isn’t really that exciting. It tries to find the configuration for the Uptime Kuma group, then checks if notifications are silenced, if they are within the configured timeframe and if this all matches an alert will be sent using Apprise. I will get to apprise in a bit. If the webhook is triggered outside of the notification times it also checks if a ticket should be required, thats the last checkbox in the configuration, and if enabled it will create a ticket instead of sending an alert waking you up in the middle of the night for something that might not need a 24/7 response.

Apprise

Why use Apprise? As they state on their github page:

Apprise allows you to send a notification to almost all of the most popular notification services available to us today such as: Telegram, Discord, Slack, Amazon SNS, Gotify, etc.

You get one super simple HTTP API and all you need to do is post your alerts to that endpoint.

Of course you could just push to whatever notification tool you want straight out of n8n, but I already had apprise in use with the other monitoring (sensu-go, working on moving to prometheus) which let’s me have a single API configuration for every need. Also the notification credentials are configure on each Apprise Config endpoint. Which means that I can just pass the required config name from n8n to apprise and apprise will just take care of notifying the correct people. I do not need to pot that login in n8n.