starred/uptime-kuma

Fork 0

mirror of https://github.com/louislam/uptime-kuma.git synced 2026-03-02 22:57:00 -05:00

Notifications: identify Uptime Kuma that sent it and/or allow customization of sent message #1466

New issue

Closed

opened 2026-02-28 02:22:10 -05:00 by deekerman · 18 comments

deekerman commented

2026-02-28 02:22:10 -05:00

Owner

Originally created by @peracchi on GitHub (Oct 7, 2022).

⚠️ Please verify that this feature request has NOT been suggested before.

I checked and didn't find similar feature request

🏷️ Feature Request Type

UI Feature, Other

🔖 Feature description

I have two instances of Uptime Kuma running: one inside my network and other outside.

Both monitoring the same few services. This helps to narrow down problems (problem it´s only accessing from inside, outside or both?).

The problem is that I can´t know wich server sent which notification.

✔️ Solution

I think the easiest/quickest solution is to add "From: - " in the beggining of each notification sent.

Ideally, some global and/or field to customize notifications, with some variables available to use.

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @peracchi on GitHub (Oct 7, 2022). ### ⚠️ Please verify that this feature request has NOT been suggested before. - [X] I checked and didn't find similar feature request ### 🏷️ Feature Request Type UI Feature, Other ### 🔖 Feature description I have two instances of Uptime Kuma running: one inside my network and other outside. Both monitoring the same few services. This helps to narrow down problems (problem it´s only accessing from inside, outside or both?). The problem is that I can´t know wich server sent which notification. ### ✔️ Solution I think the easiest/quickest solution is to add "From: <Uptime Kuma Hostname> - " in the beggining of each notification sent. Ideally, some global and/or field to customize notifications, with some variables available to use. ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman

2026-02-28 02:22:10 -05:00

closed this issue
added the
feature-request

A:notifications
labels

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@rezzorix commented on GitHub (Oct 7, 2022):

I have two instances of Uptime Kuma running: one inside my network and other outside.

Both monitoring the same few services. This helps to narrow down problems (problem it´s only accessing from inside, outside or both?).

The problem is that I can´t know wich server sent which notification.
I have the same; several instances on different servers.

Simple Solution: give your monitors distinctive "Friendly Names" either prefixes or suffixes.

E.g.:

## Instance1 ##
Instance 1 | homeserver.lan:8888
Instance 1 | homerserver.lan:9999

## Instance2 ##
Instance 2 | homeserver.lan:8888
Instance 2 | homerserver.lan:9999

etc.

@rezzorix commented on GitHub (Oct 7, 2022): > I have two instances of Uptime Kuma running: one inside my network and other outside. > > Both monitoring the same few services. This helps to narrow down problems (problem it´s only accessing from inside, outside or both?). > > The problem is that I can´t know wich server sent which notification. I have the same; several instances on different servers. Simple Solution: give your monitors distinctive "Friendly Names" either prefixes or suffixes. E.g.: ``` ## Instance1 ## Instance 1 | homeserver.lan:8888 Instance 1 | homerserver.lan:9999 ``` ``` ## Instance2 ## Instance 2 | homeserver.lan:8888 Instance 2 | homerserver.lan:9999 ``` etc.

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@peracchi commented on GitHub (Oct 8, 2022):

Simple Solution: give your monitors distinctive "Friendly Names" either prefixes or suffixes.

Good idea, thanks!

I will use your contour solution but would be better do this at "notification level" instead of "monitor´s friendly names level".

@peracchi commented on GitHub (Oct 8, 2022): > Simple Solution: give your monitors distinctive "Friendly Names" either prefixes or suffixes. Good idea, thanks! I will use your contour solution but would be better do this at _"notification level"_ instead of _"monitor´s friendly names level"_.

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@rezzorix commented on GitHub (Oct 8, 2022):

Yes customizing notifications would be nice; however fully customizing each message - dont know if that is possible or feasible.
Especially as one would need to look into each and every of the 90+ notification services to ensure there are no hiccups etc.

I am also a friend of simple solutions... one could argue that "at notification level" is already possible as you can set up as many notifications as you like (and therefore make them individual to your needs aka easier identifiable).

With some notifications (not all) you can already set e.g. a "title" or "subject".
Where this isnt possible you could use e.g. a different webhook or different channel as target to ensure knowing the source of notification.

What notification service are you mainly using?

@rezzorix commented on GitHub (Oct 8, 2022): Yes customizing notifications would be nice; however fully customizing each message - dont know if that is possible or feasible. Especially as one would need to look into each and every of the 90+ notification services to ensure there are no hiccups etc. I am also a friend of simple solutions... one could argue that "at notification level" is already possible as you can set up as many notifications as you like (and therefore make them individual to your needs aka easier identifiable). With some notifications (not all) you can already set e.g. a "title" or "subject". Where this isnt possible you could use e.g. a different webhook or different channel as target to ensure knowing the source of notification. What notification service are you mainly using?

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@peracchi commented on GitHub (Oct 9, 2022):

What notification service are you mainly using?

I'm only using Telegram.

I have several monitors, usually I configure everything in one Uptime Kuma instance, export and import they at the other.

If could be possible modify the fixed part of Telegram notification, would be necessary to do only one modification in one of the Uptime Kuma instances.

Better yet, if there was some variables to be used in a template message in Telegram notification, no modification would be necessary at all.

Something like: "%UPTIME_KUMA_HOSTNAME% - %MONITORING_FRIENDLY_NAME% - %MESSAGE%".

@peracchi commented on GitHub (Oct 9, 2022): > What notification service are you mainly using? I'm only using Telegram. I have several monitors, usually I configure everything in one Uptime Kuma instance, export and import they at the other. If could be possible modify the fixed part of Telegram notification, would be necessary to do only one modification in one of the Uptime Kuma instances. Better yet, if there was some variables to be used in a template message in Telegram notification, no modification would be necessary at all. Something like: "%UPTIME_KUMA_HOSTNAME% - %MONITORING_FRIENDLY_NAME% - %MESSAGE%".

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@rezzorix commented on GitHub (Oct 10, 2022):

I'm only using Telegram.

Seems like we run a very similar setup 😎

Better yet, if there was some variables to be used in a template message in Telegram notification, no modification would be necessary at all.

Something like: "%UPTIME_KUMA_HOSTNAME% - %MONITORING_FRIENDLY_NAME% - %MESSAGE%".

I like the idea.
However wouldn't the issue with different notification services remain as there are e.g. limited characters or charset etc.?

@rezzorix commented on GitHub (Oct 10, 2022): > I'm only using Telegram. Seems like we run a very similar setup 😎 > Better yet, if there was some variables to be used in a template message in Telegram notification, no modification would be necessary at all. > > Something like: "%UPTIME_KUMA_HOSTNAME% - %MONITORING_FRIENDLY_NAME% - %MESSAGE%". I like the idea. However wouldn't the issue with different notification services remain as there are e.g. limited characters or charset etc.?

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@peracchi commented on GitHub (Oct 10, 2022):

However wouldn't the issue with different notification services remain

Probably.

But maybe just provide some template variables and the possibility of edit the sent message of the notification service would be a great start point.

I supppose (without any real info) that Telegram and email are the most used notification services. Maybe start with implementing this idea with these ones...

@peracchi commented on GitHub (Oct 10, 2022): > However wouldn't the issue with different notification services remain Probably. But maybe just provide some template variables and the possibility of edit the sent message of the notification service would be a great start point. I supppose (without any real info) that Telegram and email are the most used notification services. Maybe start with implementing this idea with these ones...

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@vedatkamer commented on GitHub (Nov 7, 2022):

@vedatkamer commented on GitHub (Nov 7, 2022): +1

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@ahmetsoguksu commented on GitHub (Nov 7, 2022):

Here (https://github.com/louislam/uptime-kuma/pull/393), this feature has been added for Discord before. It would be good to add it for Telegram as well.

@ahmetsoguksu commented on GitHub (Nov 7, 2022): +1 Here (https://github.com/louislam/uptime-kuma/pull/393), this feature has been added for Discord before. It would be good to add it for Telegram as well.

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@PilaScat commented on GitHub (Nov 12, 2022):

@PilaScat commented on GitHub (Nov 12, 2022): +1

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@ACiDGRiM commented on GitHub (Jun 4, 2023):

I just want to provide a link to the uptime kuma instance, so I can easily click an alert to check the status from either email or matrix (or other IM service)

@ACiDGRiM commented on GitHub (Jun 4, 2023): I just want to provide a link to the uptime kuma instance, so I can easily click an alert to check the status from either email or matrix (or other IM service)

deekerman commented

2026-02-28 02:22:16 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 4, 2023):

@PilaScat @ahmetsoguksu @vedatkamer

Please refrain from posting +1 / requests for updates things on issues, as this makes issue-management harder.
Issues are for discussing what needs to be done how by whom.
We use 👍🏻 on issues to prioritise work.

@CommanderStorm commented on GitHub (Jun 4, 2023): @PilaScat @ahmetsoguksu @vedatkamer Please refrain from posting `+1` / requests for updates things on issues, as this makes issue-management harder. Issues are for discussing what needs to be done how by whom. [We use 👍🏻 on issues to prioritise work](https://github.com/louislam/uptime-kuma/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc).

deekerman commented

2026-02-28 02:22:17 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 4, 2023):

@peracchi is this a duplicate of #975 and associated discussion in #646 ?
If no, could you please edit the inital message to make this more clear.
If yes, please close this issue.
Duplicates just make issue management harder for everybody and spawn more duplicates ^^

@CommanderStorm commented on GitHub (Jun 4, 2023): @peracchi is this a duplicate of #975 and associated discussion in #646 ? If no, could you please edit the inital message to make this more clear. If yes, please close this issue. Duplicates just make issue management harder for everybody and spawn more duplicates ^^

deekerman commented

2026-02-28 02:22:17 -05:00

Author

Owner

@peracchi commented on GitHub (Jun 4, 2023):

@CommanderStorm My suggestion is a little broad than #975, which deals only with customization of the notification.

In my idea, if you do not want customize the notification, at least you already got some identification from the Uptime Kuma server that sent it.

As #975 says, notifications are only "[>>NAME OF SERVICE <<] [🔴 Down]" or "[>> NAME OF SERVICE <<] [✅ Up]".

But which server sent the notification?

The Uptime Kuma code can be modified to add some server identification on the alert even if the user do not want customize notifications.

A template or some UI to customize the notification would be a plus.

@peracchi commented on GitHub (Jun 4, 2023): @CommanderStorm My suggestion is a little broad than #975, which deals only with customization of the notification. In my idea, if you do not want customize the notification, at least you already got some identification from the Uptime Kuma server that sent it. As #975 says, notifications are only "[>>NAME OF SERVICE <<] [🔴 Down]" or "[>> NAME OF SERVICE <<] [✅ Up]". But which server sent the notification? The Uptime Kuma code can be modified to add some server identification on the alert even if the user do not want customize notifications. A template or some UI to customize the notification would be a plus.

deekerman commented

2026-02-28 02:22:17 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 4, 2023):

if you do not want customize the notification

Oh, don't get me wrong, this will eventually be a thing.
Please read through the issue above why message templating has proven difficult until now.

But which server sent the notification?

I don't fully get what you mean by "which server". Is https://github.com/louislam/uptime-kuma/tree/master/server/notification-providers what you are searching for?

@CommanderStorm commented on GitHub (Jun 4, 2023): > if you do not want customize the notification Oh, don't get me wrong, this will eventually be a thing. Please read through the issue above why message templating has proven difficult until now. > But which server sent the notification? I don't fully get what you mean by "which server". Is https://github.com/louislam/uptime-kuma/tree/master/server/notification-providers what you are searching for?

deekerman commented

2026-02-28 02:22:17 -05:00

Author

Owner

@peracchi commented on GitHub (Jun 4, 2023):

@CommanderStorm , as I said before (probably I wasn't clear enough) I have some services running on my work. These services are used by people outside the internal network and by people inside the office.

Sometimes I see a "[>>NAME OF SERVICE <<] [🔴 Down]" on my Telegram group and do not know if guys at firewall messed up and people outside office cannot reach some service OR if guys at infra messed with internal routers because Uptime Kuma outside office and Uptime Kuma inside office will send the same "[>>NAME OF SERVICE <<] [🔴 Down]".

Better explained now?

As @rezzorix suggested, I need to name the monitors something like "Service A from internal perspective" and "Service A from external perspective" to know at first sight.

If Uptime Kuma sent some self-id automatically I can share the config between Uptime Kuma internal and external (export/import backup, for example). The monitors will have the same name like just "Service A".

@peracchi commented on GitHub (Jun 4, 2023): @CommanderStorm , as I said before (probably I wasn't clear enough) I have some services running on my work. These services are used by people outside the internal network and by people inside the office. Sometimes I see a "[>>NAME OF SERVICE <<] [🔴 Down]" on my Telegram group and do not know if guys at firewall messed up and people outside office cannot reach some service OR if guys at infra messed with internal routers because Uptime Kuma outside office and Uptime Kuma inside office will send the same "[>>NAME OF SERVICE <<] [🔴 Down]". Better explained now? As @rezzorix suggested, I need to name the monitors something like "Service A from internal perspective" and "Service A from external perspective" to know at first sight. If Uptime Kuma sent some self-id automatically I can share the config between Uptime Kuma internal and external (export/import backup, for example). The monitors will have the same name like just "Service A".

deekerman commented

2026-02-28 02:22:17 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 4, 2023):

So basically #3191? (I know there is a better some other duplicate out there, but it's 2AM, and I am going to bed now)

@CommanderStorm commented on GitHub (Jun 4, 2023): So basically #3191? (I know there is a better some other duplicate out there, but it's 2AM, and I am going to bed now)

deekerman commented

2026-02-28 02:22:17 -05:00

Author

Owner

@peracchi commented on GitHub (Jun 4, 2023):

So basically #3191? (I know there is a better some other duplicate out there, but it's 2AM, and I am going to bed now)

Nope, that's for email only.

@peracchi commented on GitHub (Jun 4, 2023): > So basically #3191? (I know there is a better some other duplicate out there, but it's 2AM, and I am going to bed now) Nope, that's for email only.

deekerman commented

2026-02-28 02:22:17 -05:00

Author

Owner

@chakflying commented on GitHub (Dec 10, 2023):

Duplicate of #646

Note that for certain notification providers, you can do so manually by using a different Webhook url, and customize it's icon/bot name.

@chakflying commented on GitHub (Dec 10, 2023): Duplicate of #646 Note that for certain notification providers, you can do so manually by using a different Webhook url, and customize it's icon/bot name.