Adding templating to more notification providers

deekerman commented

2026-02-28 01:44:36 -05:00

Owner

Originally created by @deefdragon on GitHub (Oct 11, 2021).

Is it a duplicate question?

This is a potential solution to a number of other issues, consolidating them into one, and has been discussed briefly in those other issues.

Requests to have different information in the notification

#201
#543
#456
Potentiall work around for #570
when writing the new templates #543
in part (Some plugins could include custom actions via extending the filters that exist within liquidJS) #117

Potential long term bonuses/considerations

Having templates built up would allow for custom reports to be written like requested in #366 (requires a reports task system to be built up)
Would allow for inserting custom data into notifications like requested in #202 (would require saving of custom information for monitors/tags/groups/global etc.)

The messages sent in notifications have several different components which many have requested the ability to modify parts of or all of, and each of which requires translation.

Describe the solution you'd like

The implementation of a template engine such as liquidjs to allow users to customize the message sent as they see fit if they wish to do so. This would also condense the messages into as few formats as possible for translation.

Some implementations such as Discord require an object to use the API. In this case, the template would be used to generate a JSON object that would then be parsed and used as the required object.

Describe alternatives you've considered

#627 currently proposes adding regex-bassed key replacement in the email subject. It would also possible to leave the components individual and just customize/translate each one, but that would likely be a messy, hard to update solution.

Additional context

I can see 4 major steps to this.

Create the system to lookup, parse and return the templates
Alter notifications to use common, simple templates in their message
Alter front end & db to allow using custom templates
Implement global template setting

2 and 3 would have to done for the simple notifications, as well as for the JSON object implementations. 1 would basically be re-usable, however a fallback will be required in the case that the data returned from the template is not valid JSON.

I am willing to work on this, however I would like some input & other eyes before I do so. I want to make sure I am not going in the completely wrong direction. This is also a large enough change that, as has been mentioned, I want the sign off of @louislam before I go any further.

Originally created by @deefdragon on GitHub (Oct 11, 2021). ## Is it a duplicate question? This is a potential solution to a number of other issues, consolidating them into one, and has been discussed briefly in those other issues. ### Requests to have different information in the notification - #201 - #543 - #456 - Potentiall work around for #570 - when writing the new templates #543 - in part (Some plugins could include custom actions via extending the filters that exist within liquidJS) #117 ### Potential long term bonuses/considerations Having templates built up would allow for custom reports to be written like requested in #366 (requires a reports task system to be built up) Would allow for inserting custom data into notifications like requested in #202 (would require saving of custom information for monitors/tags/groups/global etc.) ## Is your feature request related to a problem? Please describe. The messages sent in notifications have several different components which many have requested the ability to modify parts of or all of, and each of which requires translation. ## Describe the solution you'd like The implementation of a template engine such as [liquidjs](https://github.com/harttle/liquidjs) to allow users to customize the message sent as they see fit if they wish to do so. This would also condense the messages into as few formats as possible for translation. Some implementations such as Discord require an object to use the API. In this case, the template would be used to generate a JSON object that would then be parsed and used as the required object. ## Describe alternatives you've considered #627 currently proposes adding regex-bassed key replacement in the email subject. It would also possible to leave the components individual and just customize/translate each one, but that would likely be a messy, hard to update solution. ## Additional context I can see 4 major steps to this. 1. Create the system to lookup, parse and return the templates 2. Alter notifications to use common, simple templates in their message 3. Alter front end & db to allow using custom templates 4. Implement global template setting 2 and 3 would have to done for the simple notifications, as well as for the JSON object implementations. 1 would basically be re-usable, however a fallback will be required in the case that the data returned from the template is not valid JSON. I am willing to work on this, however I would like some input & other eyes before I do so. I want to make sure I am not going in the completely wrong direction. This is also a large enough change that, as has been mentioned, I want the sign off of @louislam before I go any further.

deekerman added the

feature-request

A:notifications

type:enhance-existing

good first issue

labels

2026-02-28 01:44:36 -05:00

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@louislam commented on GitHub (Oct 11, 2021):

It would be really difficult in my opinion. I would suggest that it should be implemented once we have a whole picture of it.

I have a similar thoughts before, but I can't think of a good approach, because there are a lot of formats here, for example:

Line, Discord, Slack, Rocket.chat and more: All different JSON formats / payloads, also it is conditional (e.g. up = green, down = red).
Email: subject and body

Implement global template setting

With this situation, how could global template be implemented?

Alter front end

For notification like Discord, how is it look like in frontend? Textarea with json?

Current implementation

For your information, currently, there are two usages of Notification.send(...);
github.com/louislam/uptime-kuma@2a1fd93444/server/notification.js (L74)

General messages

Notification.send(notification, "Hello👋");

Sending important up/down notifications

Notification.send(notification, "[Test][🔴 Down] 404 Not Found", monitor, heartbeat);

@louislam commented on GitHub (Oct 11, 2021): It would be really difficult in my opinion. I would suggest that it should be implemented once we have a whole picture of it. I have a similar thoughts before, but I can't think of a good approach, because there are a lot of formats here, for example: - Line, Discord, Slack, Rocket.chat and more: All different JSON formats / payloads, also it is conditional (e.g. up = green, down = red). - Email: subject and body > 4. Implement global template setting With this situation, how could global template be implemented? > 3. Alter front end For notification like Discord, how is it look like in frontend? Textarea with json? ## Current implementation For your information, currently, there are two usages of Notification.send(...); https://github.com/louislam/uptime-kuma/blob/2a1fd93444d082e9d473f6548861d4aacd50dea6/server/notification.js#L74 1. General messages ```javascript Notification.send(notification, "Hello👋"); ``` 2. Sending important up/down notifications ```javascript Notification.send(notification, "[Test][🔴 Down] 404 Not Found", monitor, heartbeat); ```

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@bakeDong1 commented on GitHub (Oct 11, 2021):

how about global variable like statping

@bakeDong1 commented on GitHub (Oct 11, 2021): how about global variable like statping

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@deefdragon commented on GitHub (Oct 11, 2021):

I would suggest that it should be implemented once we have a whole picture of it.

By this, do you mean we need to the proof of concept to then iterate on? If so I will get started on it.

... there are a lot of formats here, for example:

Line, Discord, Slack, Rocket.chat and more: All different JSON formats / payloads, also it is conditional (e.g. up = green, down = red).

Email: subject and body

One of the things that came to mind would be to have different detail levels of templates. (Minimal, small, medium, large, full etc.) The defaults for emails could then have minimal in the subject and large or full in the body, Appraise::Twitter could use the small template, etc.. When Selecting what is displayed in the message, you can then choose "custom" which exposes a textarea where you can input a custom template.

As for the the conditional status, we could either make up/down templates for each, or, because its a template, we can include that in the template itself. Something to be examined in the Proof of Concept.

{% if monitor.status == "up" %}
  {{ monitor.name }} is now up.
{% else %}
  {{ monitor.name }} is now down. 
{% endif %}

Implement global template setting

With this situation, how could global template be implemented?

This was a combination of scope creep & crossed wires on my part. I was thinking about how many monitors some people had, not notifications, and reconsidering it with notifications, it would be a VERY rare situation where someone has that many notifications requiring the same template. A large number of notifications, IE on a language by language basis is possible. But not requiring the same template for many notifications.

Alter front end

For notification like Discord, how is it look like in frontend? Textarea with json?

Expanding what I have here. I see adding a "simple/advanced" toggle to the JSON endpoints.

"Simple" outputs something based on the templates explained earlier, which is then sent as a raw message.
"Advanced" mode would be able to take advantage of the features allowable in the different APIs.

Selecting "custom" for the advanced mode would then have the user generate the JSON parsed into an object which is then sent to the service.

The default advanced template would have to be added for each of the different services for translation, but I don't think that would be much more complicated than the current system, and it would centralize them.

Current implementation

[...]

I am going to have to dig into how the different .sends are called. I might start with Templates only applying for the case where monitor & heartbeat are not null.

@deefdragon commented on GitHub (Oct 11, 2021): > I would suggest that it should be implemented once we have a whole picture of it. By this, do you mean we need to the proof of concept to then iterate on? If so I will get started on it. > ... there are a lot of formats here, for example: > > * Line, Discord, Slack, Rocket.chat and more: All different JSON formats / payloads, also it is conditional (e.g. up = green, down = red). > * Email: subject and body > One of the things that came to mind would be to have different detail levels of templates. (Minimal, small, medium, large, full etc.) The defaults for emails could then have minimal in the subject and large or full in the body, Appraise::Twitter could use the small template, etc.. When Selecting what is displayed in the message, you can then choose "custom" which exposes a textarea where you can input a custom template. As for the the conditional status, we could either make up/down templates for each, or, because its a template, we can include that in the template itself. Something to be examined in the Proof of Concept. ```liquid {% if monitor.status == "up" %} {{ monitor.name }} is now up. {% else %} {{ monitor.name }} is now down. {% endif %} ``` > > 4. Implement global template setting > > With this situation, how could global template be implemented? This was a combination of scope creep & crossed wires on my part. I was thinking about how many monitors some people had, not notifications, and reconsidering it with notifications, it would be a VERY rare situation where someone has that many notifications requiring the same template. A large number of notifications, IE on a language by language basis is possible. But not requiring the same template for many notifications. > > 3. Alter front end > > For notification like Discord, how is it look like in frontend? Textarea with json? Expanding what I have [here](https://github.com/louislam/uptime-kuma/issues/456#issuecomment-939270174). I see adding a "simple/advanced" toggle to the JSON endpoints. - "Simple" outputs something based on the templates explained earlier, which is then sent as a raw message. - "Advanced" mode would be able to take advantage of the features allowable in the different APIs. Selecting "custom" for the advanced mode would then have the user generate the JSON parsed into an object which is then sent to the service. The default advanced template would have to be added for each of the different services for translation, but I don't think that would be much more complicated than the current system, and it would centralize them. > ## Current implementation > [...] I am going to have to dig into how the different `.send`s are called. I might start with Templates only applying for the case where monitor & heartbeat are not null.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@louislam commented on GitHub (Oct 12, 2021):

So it is really a large structural change.

One very important thing that I forgot to mention is, there is no auto tests of notifications. Also I believe that it is almost impossible to implement those tests.

All of them had already been tested well by hand. I am afraid that touching them would have some unpredictable situations that make notifications unstable as a result.

Recently, I actually rejected a big pull request, because there is no way for me to verify the change completely. (#568)

I prefer not to implement this, just because of the testing problem.

Instead, at this moment, I would prefer the approach like #627. Each pull request just modify one notification. It is easy for me to check one by one.

But I agree that we should use the parser like liquidjs instead of regex.

@louislam commented on GitHub (Oct 12, 2021): So it is really a large structural change. One very important thing that I forgot to mention is, there is no auto tests of notifications. Also I believe that it is almost impossible to implement those tests. All of them had already been tested well by hand. I am afraid that touching them would have some unpredictable situations that make notifications unstable as a result. Recently, I actually rejected a big pull request, because there is no way for me to verify the change completely. (#568) I prefer not to implement this, just because of the testing problem. Instead, at this moment, I would prefer the approach like #627. Each pull request just modify one notification. It is easy for me to check one by one. But I agree that we should use the parser like liquidjs instead of regex.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@deefdragon commented on GitHub (Oct 12, 2021):

I can think of a potential solution to the testing problem, but I understand the not wanting to take on such a large change until that is implemented.

Would you be willing to consider it if I limited it in scope to not include the complex JSON cases for now? The changes would be limited to around here
github.com/louislam/uptime-kuma@0550ceb6d4/server/model/monitor.js (L328)
(I was not aware how literal you were being when you said that there were 2 calls to Notification.send. I thought you meant two types of calls)

@deefdragon commented on GitHub (Oct 12, 2021): I can think of a _potential_ solution to the testing problem, but I understand the not wanting to take on such a large change until that is implemented. Would you be willing to consider it if I limited it in scope to not include the complex JSON cases for now? The changes would be limited to around here https://github.com/louislam/uptime-kuma/blob/0550ceb6d42f6c9a2d6233d17230e79951953e04/server/model/monitor.js#L328 (I was not aware how literal you were being when you said that there were 2 calls to `Notification.send`. I thought you meant two types of calls)

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@PopcornPanda commented on GitHub (Oct 12, 2021):

I think, there is no need for changing notification system itself. It could be basically a template engine that generate body from arguments.
Something like this:

msg = template(templateName,monitorJSON,heartbeatJSON,someExtraArgs...)

Where templateName is name of predefined template which we could create in dashboard. Maybe there should also be a way to pass template as a string like this:

msg = template("[{{NAME}}] {{$t(has changed status to)}} {{STATUS}}",monitorJSON,heartbeatJSON,someExtraArgs...)

For multilanguage support, text in $t() could be translated like in vue files.

If it only generates a text, then it should be safe for existing notifications (because it doesn't touch them) and simple to test. Just change ready msg to result of template engine in one notification provider at a time and check provider itself.

I'm not a nodejs dev, and I don't know that this has any sense in this language. In ruby ERB just handles generating content from templates and You just use result where You need it.

@PopcornPanda commented on GitHub (Oct 12, 2021): I think, there is no need for changing notification system itself. It could be basically a template engine that generate body from arguments. Something like this: ``` msg = template(templateName,monitorJSON,heartbeatJSON,someExtraArgs...) ``` Where templateName is name of predefined template which we could create in dashboard. Maybe there should also be a way to pass template as a string like this: ``` msg = template("[{{NAME}}] {{$t(has changed status to)}} {{STATUS}}",monitorJSON,heartbeatJSON,someExtraArgs...) ``` For multilanguage support, text in $t() could be translated like in vue files. If it only generates a text, then it should be safe for existing notifications (because it doesn't touch them) and simple to test. Just change ready msg to result of template engine in one notification provider at a time and check provider itself. I'm not a nodejs dev, and I don't know that this has any sense in this language. In ruby ERB just handles generating content from templates and You just use result where You need it.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@deefdragon commented on GitHub (Oct 13, 2021):

So, I have started on this, and gotten a quick and dirty example to work.
While parsing the template in place of msg on line 328 can work, I am once again wondering if it would be better to put the template parsing inside Notification.send, and not 328.

I wonder this because I think that when a test notification is sent, it could include some mock objects for the monitor and heartbeat. Combined with parsing the template in Notification.send, the user will be able to not only test connection to the notification provider etc, but also be able to see what the notification will look like when received.

@deefdragon commented on GitHub (Oct 13, 2021): So, I have started on this, and gotten a quick and dirty example to work. While parsing the template in place of `msg` on line 328 can work, I am once again wondering if it would be better to put the template parsing inside `Notification.send`, and not 328. I wonder this because I think that when a test notification is sent, it could include some mock objects for the monitor and heartbeat. Combined with parsing the template in `Notification.send`, the user will be able to not only test connection to the notification provider etc, but also be able to see what the notification will look like when received.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@Hamitamaru commented on GitHub (Oct 14, 2021):

Was just about to cut a separate issue for the Slack particular notification improvement I would like to see but I found this one.

If I run this:

curl -X POST -H 'Content-type: application/json' --data '{"text": "[✅ Up][plex]","username": "uptime-kuma","blocks": [{"type": "header","text": {"type": "plain_text","text": "Uptime Kuma Alert 2",},},{"type": "section","fields": [{"type": "mrkdwn","text": "*Message*\n la2"},{"type": "mrkdwn","text": "*Time (UTC)*\n la"}]}]}' https://hooks.slack.com/services/replaceThisLinkWithYourSlackAppIncomingWebHookUrl

I get a more useful notification on my android phone that shows [✅ Up][plex] rather than less useful Uptime Kuma Alert so I don't need to open slack to understand what has changed (what went up or down).

Not sure what template variables we are adding support for, so far I've seen
[{{NAME}}] I guess this is the name of the monitor stored in monitorJSON["name"]
[{{STATUS}}] I guess this is the value in heartbeatJSON["status"]

Can we create template variables scheme that allow for arbitrary key access in both monitorJSON and heartbeatJSON e.g.
[{{monitor-name}}] results in monitorJSON["name"]
[{{heartbeat-status}}] results in heartbeatJSON["status"]

Aside from that arbitrary template variable scheme for access to those JSON variables if we can also find a way to accomplish:
[✅ Up] and the down equivalent via some template variable that would help my case.

@Hamitamaru commented on GitHub (Oct 14, 2021): Was just about to cut a separate issue for the Slack particular notification improvement I would like to see but I found this one. If I run this: `curl -X POST -H 'Content-type: application/json' --data '{"text": "[✅ Up][plex]","username": "uptime-kuma","blocks": [{"type": "header","text": {"type": "plain_text","text": "Uptime Kuma Alert 2",},},{"type": "section","fields": [{"type": "mrkdwn","text": "*Message*\n la2"},{"type": "mrkdwn","text": "*Time (UTC)*\n la"}]}]}' https://hooks.slack.com/services/replaceThisLinkWithYourSlackAppIncomingWebHookUrl ` I get a more useful notification on my android phone that shows `[✅ Up][plex]` rather than less useful `Uptime Kuma Alert` so I don't need to open slack to understand what has changed (what went up or down). Not sure what template variables we are adding support for, so far I've seen [{{NAME}}] I guess this is the name of the monitor stored in monitorJSON["name"] [{{STATUS}}] I guess this is the value in heartbeatJSON["status"] Can we create template variables scheme that allow for arbitrary key access in both monitorJSON and heartbeatJSON e.g. [{{monitor-name}}] results in monitorJSON["name"] [{{heartbeat-status}}] results in heartbeatJSON["status"] Aside from that arbitrary template variable scheme for access to those JSON variables if we can also find a way to accomplish: `[✅ Up]` and the down equivalent via some template variable that would help my case.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@deefdragon commented on GitHub (Oct 14, 2021):

@Hamitamaru unfortunately, the more complex notification types like slack/discord are going to take a bit to implement. The notification message can be changed using a template without much worry as it's just text. Discord/Slack etc.'s richer features on the other hand will each require wiring up and testing individually to account for their different formats.

The templates should have access to the entire monitor and heartbeat objects (minus some potential sanitization). I also suspect there will be a number of helpers included such as ✅ Up, But time will tell on the full details.

@deefdragon commented on GitHub (Oct 14, 2021): @Hamitamaru unfortunately, the more complex notification types like slack/discord are going to take a bit to implement. The notification message can be changed using a template without much worry as it's just text. Discord/Slack etc.'s richer features on the other hand will each require wiring up and testing individually to account for their different formats. The templates should have access to the entire monitor and heartbeat objects (minus some potential sanitization). I also suspect there will be a number of helpers included such as `✅ Up`, But time will tell on the full details.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@deefdragon commented on GitHub (Oct 17, 2021):

Question on translation: Do we have the a way to translate things server side? I'm not seeing any previous uses, and part of why I started this was so that the default templates could be translated.

@deefdragon commented on GitHub (Oct 17, 2021): Question on translation: Do we have the a way to translate things server side? I'm not seeing any previous uses, and part of why I started this was so that the default templates could be translated.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@tiakun commented on GitHub (Mar 25, 2022):

Would it be easier if this is implemented not globally but per notification type? It would also allow the customization per notification type, e.g. some users might want short message for SMS but longer messages for chat/message apps.

@tiakun commented on GitHub (Mar 25, 2022): Would it be easier if this is implemented not globally but per notification type? It would also allow the customization per notification type, e.g. some users might want short message for SMS but longer messages for chat/message apps.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@deefdragon commented on GitHub (Mar 25, 2022):

It would be easier, but it would make the notifications aspect of uptime kuma even more of a dis-congruous mess.

The ideal would be to have a consistent notification form/message for everything, and while it's ok now, it could be much better.

The thing is, there are other aspects of UK that should get worked on first (groups, notification controls/cascading etc). Louis only has so much time to test, and addressing the notifications system is rather low on the list.

I'm going to close this issue for now, as it is very likely not going to get addressed until a V2/notifications core code re-write.

@deefdragon commented on GitHub (Mar 25, 2022): It would be easier, but it would make the notifications aspect of uptime kuma even more of a dis-congruous mess. The ideal would be to have a consistent notification form/message for everything, and while it's ok now, it could be much better. The thing is, there are other aspects of UK that should get worked on first (groups, notification controls/cascading etc). Louis only has so much time to test, and addressing the notifications system is rather low on the list. I'm going to close this issue for now, as it is very likely not going to get addressed until a V2/notifications core code re-write.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

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

Re-opening this since I think this is a better place to keep track of all the duplicates.

Realistically it probably won't happen before 2.2.0 at the earliest, but fundamentally the issue still exists and this is the most practical way of solving it.

@chakflying commented on GitHub (Dec 6, 2023): Re-opening this since I think this is a better place to keep track of all the duplicates. Realistically it probably won't happen before 2.2.0 at the earliest, but fundamentally the issue still exists and this is the most practical way of solving it.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@Qumans commented on GitHub (May 5, 2024):

Since Feishu notifications can only fix templates, and I wanted to customize the content, I used webhook, and the url was the Feishu bot's webhook url. After clicking the test, it shows that the delivery was successful, but there is no message for my flying book. I can receive the flying book after testing with postman. And many times will appear Error: Error: getaddrinfo ENOTFOUND open.feishu.cn. Whatever the form of notification

@Qumans commented on GitHub (May 5, 2024): Since Feishu notifications can only fix templates, and I wanted to customize the content, I used webhook, and the url was the Feishu bot's webhook url. After clicking the test, it shows that the delivery was successful, but there is no message for my flying book. I can receive the flying book after testing with postman. And many times will appear Error: Error: getaddrinfo ENOTFOUND open.feishu.cn. Whatever the form of notification

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@Qumans commented on GitHub (May 5, 2024):

Why did I not receive the message after kuma successfully sent it? Same url, same body, but I get messages through postman@

@Qumans commented on GitHub (May 5, 2024): Why did I not receive the message after kuma successfully sent it? Same url, same body, but I get messages through postman@

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 6, 2024):

@Qumans
You are posting this in the wrong place/issue.
=> Please open a new issue and include full context of what you tried and what works in Postman via screenshots.

There are a lot of cases that MIGHT be wrong:
It might be because of your network, your DNS or because the notification provider had an outage. Debugging these cases is not something that this issue is a good place to do, this issue is about implementing notification-templates not using the webhook notification provider.
Some basic troubleshooting steps are writtten down here:
https://github.com/louislam/uptime-kuma/wiki/Troubleshooting

@CommanderStorm commented on GitHub (May 6, 2024): @Qumans You are posting this in the wrong place/issue. => Please [open a new issue](https://github.com/louislam/uptime-kuma/issues/new/choose) and include full context of what you tried and what works in Postman via screenshots. There are a lot of cases that MIGHT be wrong: It might be because of your network, your DNS or because the notification provider had an outage. Debugging these cases is not something that this issue is a good place to do, this issue is about implementing notification-templates not using the webhook notification provider. Some basic troubleshooting steps are writtten down here: https://github.com/louislam/uptime-kuma/wiki/Troubleshooting

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@borrelan commented on GitHub (Aug 8, 2024):

Hello,

I would like to thank the team behind Uptime Kuma for such an awesome service that I have come to depend on. As this issue is ongoing, would you be willing to consider change the static entry of "[Uptime Kuma]" in the ntfy notification to include the "Friendly Name"? When you have more than one instance pushing to the same topic it makes it difficult to determine which instance is pushing the notification. One could also argue what's the point of the setting "Friendly Name" if it's not used?

Thanks again!!!

@borrelan commented on GitHub (Aug 8, 2024): Hello, I would like to thank the team behind Uptime Kuma for such an awesome service that I have come to depend on. As this issue is ongoing, would you be willing to consider change the static entry of "[Uptime Kuma]" in the ntfy notification to include the "Friendly Name"? When you have more than one instance pushing to the same topic it makes it difficult to determine which instance is pushing the notification. One could also argue what's the point of the setting "Friendly Name" if it's not used? Thanks again!!!

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@realies commented on GitHub (Aug 29, 2024):

i see a lot of text duplication when i add a slack webhook notification

the notification friendly name is Uptime Kuma and the webhook name is Uptime Kuma

is there a way to remove the friendly name from the notification text? or even the whole "Uptime Kuma Alert" row altogether?

@realies commented on GitHub (Aug 29, 2024): <img width="251" alt="Screenshot 2024-08-30 at 02 52 16" src="https://github.com/user-attachments/assets/3776a1ab-6af7-4e02-8292-704881e8fb0d"> i see a lot of text duplication when i add a slack webhook notification the notification friendly name is Uptime Kuma and the webhook name is Uptime Kuma is there a way to remove the friendly name from the notification text? or even the whole "Uptime Kuma Alert" row altogether?

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Aug 29, 2024):

Removing that line is likely fine, feel free to provide a PR.
Given the number of notifications providers and maintainers I can't afford timewise to fix and test this myself
=> we are quite heavily reliant on contributors in this department, see our contribution guide ^^

PS: for the future, consider opening on new issues. For specific issues, which are not closely related to their parents, this otherwise spams too many people.

If you are instead looking for message templating, that code is in master but needs to be lifted from the SMTP/webhook implementations into one that can be shared between all monitors.
This would allow other monitors to make fields properly templated.
PRs welcome..

@CommanderStorm commented on GitHub (Aug 29, 2024): Removing that line is likely fine, feel free to provide a PR. Given the number of notifications providers and maintainers I can't afford timewise to fix and test this myself => we are quite heavily reliant on contributors in this department, see our contribution guide ^^ PS: for the future, consider opening on new issues. For specific issues, which are not closely related to their parents, this otherwise spams too many people. If you are instead looking for message templating, that code is in master but needs to be lifted from the SMTP/webhook implementations into one that can be shared between all monitors. This would allow other monitors to make fields properly templated. PRs welcome..

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@frauberawg commented on GitHub (Mar 18, 2025):

Would it be possible to revisit the topic of implementing templates for notifications in Uptime Kuma? This feature would allow for greater customization of messages and make translation easier.

@frauberawg commented on GitHub (Mar 18, 2025): Would it be possible to revisit the topic of implementing templates for notifications in Uptime Kuma? This feature would allow for greater customization of messages and make translation easier.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Mar 18, 2025):

It is gradually being introduced. Feel free to send a Pull request for notification providers.
Currently, we have webhooks,telegram and mails templated.

(FYI: I am a bit behind on reviews. Might be w bit before I get to any. Any help in this area or with issues is also appreciated)

@CommanderStorm commented on GitHub (Mar 18, 2025): It is gradually being introduced. Feel free to send a Pull request for notification providers. Currently, we have webhooks,telegram and mails templated. (FYI: I am a bit behind on reviews. Might be w bit before I get to any. Any help in this area or with issues is also appreciated)

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@PilaScat commented on GitHub (Mar 18, 2025):

@PilaScat commented on GitHub (Mar 18, 2025): Telegram

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@echandler-anl commented on GitHub (Mar 18, 2025):

We'd like this for Microsoft Teams notifications

@echandler-anl commented on GitHub (Mar 18, 2025): We'd like this for Microsoft Teams notifications

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@crashedthecymbal commented on GitHub (Mar 22, 2025):

I just tried a push monitor, to see if a script ran. I know, Uptime Kuma is not meant to do that, but it is already very close to healthchecks.io

SInce the script runs only once / day - I used the "Upside Down Mode".
It's working okay, the "red/down" now means the script ran.
The notification allthough is really confusing. This could be solved with a custom message.

The custom messages as simple variables which can be set in the Settings/Notifications section

When the variables / messages (2 variables - 1 for Up/OK and 1 for down/No heartbeat in this time window) is set it will overwrite the defaults (OK / No heartbeat in the time window )

Script ran with push monitor in Upside Down Mode

Notifications in Gotify are confusing and could be resolved with custom messages

Instead of OK -> My custom message like: "Script just ran"
Inseat of No heartbeat in the time window -> My custom message like: "Script will ran again in 24h"

@crashedthecymbal commented on GitHub (Mar 22, 2025): I just tried a push monitor, to see if a script ran. I know, Uptime Kuma is not meant to do that, but it is already very close to healthchecks.io SInce the script runs only once / day - I used the "Upside Down Mode". It's working okay, the "red/down" now means the script ran. The notification allthough is really confusing. This could be solved with a custom message. The custom messages as simple variables which can be set in the Settings/Notifications section ![Image](https://github.com/user-attachments/assets/ba776021-1537-4232-b266-131ef3c47f0a) When the variables / messages (2 variables - 1 for Up/OK and 1 for down/No heartbeat in this time window) is set it will overwrite the defaults (OK / No heartbeat in the time window ) Script ran with push monitor in Upside Down Mode ![Image](https://github.com/user-attachments/assets/df77ee09-64af-40b5-990f-5889e7e99e3d) Notifications in Gotify are confusing and could be resolved with custom messages ![Image](https://github.com/user-attachments/assets/c157dcfa-9e48-4359-ab3f-e7978596c7d8) Instead of OK -> My custom message like: "Script just ran" Inseat of No heartbeat in the time window -> My custom message like: "Script will ran again in 24h"

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@JanC commented on GitHub (Apr 23, 2025):

hey there,
is there any work being done for supporting the notification templates? That would be a great feature. Happy to contrinute if needed.

@JanC commented on GitHub (Apr 23, 2025): hey there, is there any work being done for supporting the notification templates? That would be a great feature. Happy to contrinute if needed.

deekerman commented

2026-02-28 01:44:40 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Apr 23, 2025):

Yes. The status from https://github.com/louislam/uptime-kuma/issues/646#issuecomment-2732953980 is still accurate though.

If you use a notification provider we don't support this feature on, we would love for a PR.

@CommanderStorm commented on GitHub (Apr 23, 2025): Yes. The status from https://github.com/louislam/uptime-kuma/issues/646#issuecomment-2732953980 is still accurate though. If you use a notification provider we don't support this feature on, we would love for a PR.

deekerman commented

2026-02-28 01:44:41 -05:00

Author

Owner

@PilaScat commented on GitHub (May 22, 2025):

{{ status }} tells only up, down and test, no maintenance status, should be added

@PilaScat commented on GitHub (May 22, 2025): {{ status }} tells only up, down and test, no maintenance status, should be added

deekerman commented

2026-02-28 01:44:41 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 22, 2025):

Maintenances stop all notifications. That is intentional.

Notifying on maintenance start is a different FR

@CommanderStorm commented on GitHub (May 22, 2025): Maintenances stop all notifications. That is intentional. Notifying on maintenance start is a different FR

deekerman commented

2026-02-28 01:44:41 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 27, 2025):

Since there has been some confusing what it takes to enable templating on a notification provider.

Basicallly, applying the changes from src/components/notifications/Telegram.vue and server/notification-providers/telegram.js from the following PR (it also laid grond work in other notification providers) are nessesary.

https://github.com/louislam/uptime-kuma/pull/5637

Afterwards, testing that it still works is required.

@CommanderStorm commented on GitHub (May 27, 2025): Since there has been some confusing what it takes to enable templating on a notification provider. Basicallly, applying the changes from `src/components/notifications/Telegram.vue` and `server/notification-providers/telegram.js` from the following PR (it also laid grond work in other notification providers) are nessesary. - https://github.com/louislam/uptime-kuma/pull/5637 Afterwards, testing that it still works is required.

deekerman commented

2026-02-28 01:44:41 -05:00

Author

Owner

@crashedthecymbal commented on GitHub (Jun 2, 2025):

When using Gotify, I would like to see the "Friendly Name" as message heading - instead of "Uptime-Kuma".
If you add multiple monitors in Uptime-Kuma, every notification in Gotify has the big heading "Uptime-Kuma", followed by a smaller one, which gives you the actual affected service/app.

Screenshot - Use the "The Friendly Name" as heading - instead of "Uptime-Kuma"

@crashedthecymbal commented on GitHub (Jun 2, 2025): When using Gotify, I would like to see the "Friendly Name" as message heading - instead of "Uptime-Kuma". If you add multiple monitors in Uptime-Kuma, every notification in Gotify has the big heading "Uptime-Kuma", followed by a smaller one, which gives you the actual affected service/app. Screenshot - Use the "The Friendly Name" as heading - instead of "Uptime-Kuma" ![Image](https://github.com/user-attachments/assets/183f5538-7986-466a-96a0-3616829fd377)

deekerman commented

2026-02-28 01:44:41 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 2, 2025):

Your FR is not related to templating.
Please discuss this in a different issue

@CommanderStorm commented on GitHub (Jun 2, 2025): Your FR is not related to templating. Please discuss this in a different issue

Rows
Columns

Adding templating to more notification providers #380

Is it a duplicate question?

Requests to have different information in the notification

Potential long term bonuses/considerations

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

Describe alternatives you've considered

Additional context

Current implementation

Current implementation