starred/uptime-kuma

Fork 0

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

Tokens for Notifications? #3010

New issue

Closed

opened 2026-02-28 03:14:41 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-28 03:14:41 -05:00

Owner

Originally created by @YouveGotMeowxy on GitHub (Jan 8, 2024).

⚠️ Please verify that this question has NOT been raised before.

I checked and didn't find similar issue

🛡️ Security Policy

I agree to have read this project Security Policy

📝 Describe your problem

Is there a way to use a token when creating a notification?

Case Example:

I am adding a ton of docker containers to monitor and I want them all to use the same Gotify notification via Apprise.

I can either 1-by-1 manually add the same gotify://gotify/<token> to each one, and hand edit the "Friendly Name" to match each docker container, and set the below toggles to off so they don't affect all current, or new monitors, or do like this:

and it'll use whatever was entered into the Friendly Name field; and keep the toggles enabled so all new monitors automatically get the same notifications settings, with the name dynamically used via the token.

Apologies if this already exists, but I did a quick look through the docs and didn't see it.

📝 Error Message(s) or Log

No response

🐻 Uptime-Kuma Version

1.23.11

💻 Operating System and Arch

Docker container

🌐 Browser

Brave

🐋 Docker Version

latest

🟩 NodeJS Version

No response

Originally created by @YouveGotMeowxy on GitHub (Jan 8, 2024). ### ⚠️ Please verify that this question has NOT been raised before. - [X] I checked and didn't find similar issue ### 🛡️ Security Policy - [X] I agree to have read this project [Security Policy](https://github.com/louislam/uptime-kuma/security/policy) ### 📝 Describe your problem Is there a way to use a token when creating a notification? Case Example: I am adding a ton of docker containers to monitor and I want them all to use the same Gotify notification via Apprise. I can either 1-by-1 manually add the same `gotify://gotify/<token>` to each one, and hand edit the "Friendly Name" to match each docker container, and set the below toggles to off so they don't affect all current, or new monitors, or do like this: ![image](https://github.com/louislam/uptime-kuma/assets/39491297/be81966f-4823-4160-9180-f5882edcaf28) and it'll use whatever was entered into the Friendly Name field; and keep the toggles enabled so all new monitors automatically get the same notifications settings, with the name dynamically used via the token. Apologies if this already exists, but I did a quick look through the docs and didn't see it. ### 📝 Error Message(s) or Log _No response_ ### 🐻 Uptime-Kuma Version 1.23.11 ### 💻 Operating System and Arch Docker container ### 🌐 Browser Brave ### 🐋 Docker Version latest ### 🟩 NodeJS Version _No response_

deekerman

2026-02-28 03:14:41 -05:00

closed this issue
added the
A:notifications

help
labels

deekerman commented

2026-02-28 03:14:47 -05:00

Author

Owner

@larswmh commented on GitHub (Jan 9, 2024):

Hey @YouveGotMeowxy,

I hope I've understood your issue correctly. You're not that far from the correct solution here.

The "Friendly Name" input field is just for how you want that notification to be called when it's listed on monitors, see here:

"Title" can be left empty, but feel free to put whatever you want in there. When a notification is sent to Gotify, the monitor name will be sent anyway. I've set this up in a test enviroment to check:

This way, you should easily be able to just create the monitors for your docker containers with that notification being set as default, without having to configure each monitors notification individually

@larswmh commented on GitHub (Jan 9, 2024): Hey @YouveGotMeowxy, I hope I've understood your issue correctly. You're not that far from the correct solution here. The "Friendly Name" input field is just for how you want that notification to be called when it's listed on monitors, see here: ![image](https://github.com/louislam/uptime-kuma/assets/88365935/8a998bc5-d5bc-4147-98fe-cafd40da9c51) "Title" can be left empty, but feel free to put whatever you want in there. When a notification is sent to Gotify, the monitor name will be sent anyway. I've set this up in a test enviroment to check: ![image](https://github.com/louislam/uptime-kuma/assets/88365935/5ee51395-91d9-405e-b4fb-d5ac5f994e87) This way, you should easily be able to just create the monitors for your docker containers with that notification being set as default, without having to configure each monitors notification individually

deekerman commented

2026-02-28 03:14:47 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 9, 2024):

Sort of related #1323

I don't think that templating in the notification providers settings (!= send messages, this is tracked in #646) is a good idea, as the added complexity would just confuse users.

@larswmh a helptext should be added (discovering something via testing how it works is not ideal UX)

@YouveGotMeowxy
Instead of creating such monitors by hand, you might want to consider using third party tooling like https://pypi.org/project/uptime-kuma-api/ to automate this until we support either config tempaltes or templating for notifications

=> I am closing this as a duplicate. If I understood something wrong, please reopen ^^

@CommanderStorm commented on GitHub (Jan 9, 2024): Sort of related #1323 I don't think that templating in the notification providers settings (!= send messages, this is tracked in #646) is a good idea, as the added complexity would just confuse users. @larswmh a helptext should be added (discovering something via testing how it works is not ideal UX) @YouveGotMeowxy Instead of creating such monitors by hand, you might want to consider using third party tooling like https://pypi.org/project/uptime-kuma-api/ to automate this until we support either config tempaltes or templating for notifications => I am closing this as a duplicate. If I understood something wrong, please reopen ^^

deekerman commented

2026-02-28 03:14:47 -05:00

Author

Owner

@YouveGotMeowxy commented on GitHub (Jan 9, 2024):

Hi guys,

All I really mean is not so much "templating", but simply having a few 'tokens' that get replaced with the text from the already entered fields in the Edit -> General section for a service. Technically yes, it's 'templating', but I don't really mean a complicated templating system; just a couple essentially search & replaces in the form of tokens.

for example:

if the above-mentioned fields contain:

friendly name: Bazaar
Server URL: https://bazarr.my.domain

then using the tokens:

%FRIENDLYNAME% and %URL% in the Notifications fields would replace the tokens with their respective text.

%FRIENDLYNAME% -> "Bazaar"

%URL% -> "https://bazarr.my.domain"

Then we would simply create 1 notification containing those tokens in their respective fields, and toggle the Default Enabled to On, and any new services created will automatically use the above in those fields.

(as also shown in the screenshot, the already created notifications have been manually created for each monitor. Every single one of those are exact clones, with the exception of me having to manually enter the same text as I entered in the Friendly Name and Server URL fields into the notification fields.
This seems like a lot of waste since they're all exact clones in terms of the Gotify token used, and also more minutiae/micro-managing than seems necessary, having to create tons of clones, manually copying and pasting into the Notification fields. Those clones would ALL be replaced with a single notification, since it would be using replacement tokens.)

In my case, I am using an auto-adder:

https://github.com/linuxserver/docker-mods/tree/swag-auto-uptime-kuma

So I when I add these labels to my docker compose:

    labels:
      swag.uptime-kuma.monitor.name: "Crowdsec"
      swag.uptime-kuma.monitor.url: "https://crowdsec.my.domain"

the notification would automatically use those in place of the tokens. Completely automating creating properly labeled notifications as well (the way we like them personalized), when the new monitor is added. :)

Other replacement tokens could be created as well as you all feel like adding, but in my case, those 2 would be plenty.

@YouveGotMeowxy commented on GitHub (Jan 9, 2024): Hi guys, All I really mean is not so much "templating", but simply having a few 'tokens' that get replaced with the text from the already entered fields in the Edit -> General section for a service. Technically yes, it's 'templating', but I don't really mean a complicated templating system; just a couple essentially search & replaces in the form of tokens. for example: if the above-mentioned fields contain: ``` friendly name: Bazaar Server URL: https://bazarr.my.domain ``` then using the tokens: `%FRIENDLYNAME%` and `%URL%` in the Notifications fields would _replace_ the tokens with their respective text. `%FRIENDLYNAME%` -> "Bazaar" `%URL%` -> "https://bazarr.my.domain" Then we would simply create 1 notification containing those tokens in their respective fields, and toggle the `Default Enabled` to On, and any new services created will automatically use the above in those fields. ![image](https://github.com/louislam/uptime-kuma/assets/39491297/ab3bece9-711c-4b56-8690-3cffea25953c) (as also shown in the screenshot, the already created notifications have been manually created for each monitor. Every single one of those are exact clones, with the exception of me having to manually enter the same text as I entered in the Friendly Name and Server URL fields into the notification fields. This seems like a lot of waste since they're all exact clones in terms of the Gotify token used, and also more minutiae/micro-managing than seems necessary, having to create tons of clones, manually copying and pasting into the Notification fields. Those clones would ALL be replaced with a single notification, since it would be using replacement tokens.) In my case, I am using an auto-adder: https://github.com/linuxserver/docker-mods/tree/swag-auto-uptime-kuma So I when I add these labels to my docker compose: ``` labels: swag.uptime-kuma.monitor.name: "Crowdsec" swag.uptime-kuma.monitor.url: "https://crowdsec.my.domain" ``` the notification would automatically use those in place of the tokens. Completely automating creating properly labeled notifications as well (the way we like them personalized), when the new monitor is added. :) Other replacement tokens could be created as well as you all feel like adding, but in my case, those 2 would be plenty.

deekerman commented

2026-02-28 03:14:47 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jan 9, 2024):

just a couple essentially search & replaces

I don't see this as a maintainable solution going forward.
Such a solution would require additional work like #3414 (which also means breaking changes for our users) in the future.
I can't speak for the other maintainers, but I think we need not add bodges, which require more effort to fix in the future.

Have you asked the integration if this would be a configuration option that they could support for now?

Warning

Please be aware of these issues (both seem related as they both are triggered by removing a container) with the product you showed:

https://github.com/linuxserver/docker-mods/issues/789

https://github.com/linuxserver/docker-mods/issues/787

@CommanderStorm commented on GitHub (Jan 9, 2024): > just a couple essentially search & replaces I don't see this as a maintainable solution going forward. Such a solution would require additional work like #3414 (which also means breaking changes for our users) in the future. I can't speak for the other maintainers, but I think we need not add [bodges](https://www.youtube.com/watch?v=lIFE7h3m40U), which require more effort to fix in the future. Have you asked the integration if this would be a configuration option that they could support for now? > [!WARNING] > Please be aware of these issues (both seem related as they both are triggered by removing a container) with the product you showed: > - https://github.com/linuxserver/docker-mods/issues/789 > - https://github.com/linuxserver/docker-mods/issues/787