starred/uptime-kuma

Fork 0

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

Email Notifications #2208

New issue

Closed

opened 2026-02-28 02:46:34 -05:00 by deekerman · 4 comments

deekerman commented

2026-02-28 02:46:34 -05:00

Owner

Originally created by @evdev on GitHub (May 24, 2023).

⚠️ 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

🔖 Feature description

Can you please enhance the email notification option to allow customizing the body of the email?
Would it be possible to add a variable for email addresses for each monitor and to send a notification to the email addresses in the variable? This way I won't need to configure a notification type for each email address I would like to send to and it can instead send the email automatically to the listed email addresses in the local variable of the monitored entity.

✔️ Solution

add a customization field for the body
add variable to each monitor and allow the variable to be used for the monitor's notifications

❓ Alternatives

No response

📝 Additional Context

No response

Originally created by @evdev on GitHub (May 24, 2023). ### ⚠️ 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 ### 🔖 Feature description Can you please enhance the email notification option to allow customizing the body of the email? Would it be possible to add a variable for email addresses for each monitor and to send a notification to the email addresses in the variable? This way I won't need to configure a notification type for each email address I would like to send to and it can instead send the email automatically to the listed email addresses in the local variable of the monitored entity. ### ✔️ Solution add a customization field for the body add variable to each monitor and allow the variable to be used for the monitor's notifications ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_

deekerman

2026-02-28 02:46:34 -05:00

closed this issue
added the
feature-request
label

deekerman commented

2026-02-28 02:46:41 -05:00

Author

Owner

@prohand commented on GitHub (May 24, 2023):

Hello, great feature :)
hope it is implemented

@prohand commented on GitHub (May 24, 2023): Hello, great feature :) hope it is implemented

deekerman commented

2026-02-28 02:46:41 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 24, 2023):

@evdev
Customising the body of mails is tracked in #1529, please don't post duplicate issues, as this makes issue management harder.

Handling emails like this would be very messy. Not everybody wants email notifications.
=> I don't think Uptime Kuma should modify the Notification system like this.
If you really need this feature, you could achieve this with other email filtering tools like Sieve.

Please go into detail about your intended use case, if you really need this.

@CommanderStorm commented on GitHub (May 24, 2023): @evdev Customising the body of mails is tracked in #1529, please don't post duplicate issues, as this makes issue management harder. Handling emails like this would be very messy. Not everybody wants email notifications. => I don't think Uptime Kuma should modify the Notification system like this. If you really need this feature, you could achieve this with other email filtering tools like Sieve. Please go into detail about your intended use case, if you really need this.

deekerman commented

2026-02-28 02:46:41 -05:00

Author

Owner

@CommanderStorm commented on GitHub (May 24, 2023):

@prohand
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 (May 24, 2023): @prohand 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:46:41 -05:00

Author

Owner

@evdev commented on GitHub (May 24, 2023):

@CommanderStorm

Thanks for your prompt response. I will look into Sieve.

The reason I am asking for this feature is because my use case is probably a bit different than the typical IT usage where you are monitoring internal and cloud based systems for which only a few stakeholders are responsible. In my case the monitored devices are spread out across many sites in clients homes. If the device is down it is probably due to an internet or power issue which needs to be resolved by the contact on site. That is why I would prefer that the emails go directly to the one responsible for it. The way it is setup now, to accomplish this I need to setup a notification with all of the SMTP info for each recipient even though they are only monitoring a single device. I hope that helps.

While this might not be the most common use case I don't think it is so fringe. The way it is setup now assumes that notifications will only be going out to a few people, but sometimes even with one organization the person being notified may only need to know about the uptime of 1 or 2 entities. That is why I am suggesting that the credentials for authentication be stored separately from the intended recipient. So this would apply to phone numbers, emails addresses, handles etc. To preserve current functionality perhaps the currently configured recipient can be configured as the default recipient unless a different one is specified with the monitored entity.

@evdev commented on GitHub (May 24, 2023): @CommanderStorm Thanks for your prompt response. I will look into Sieve. The reason I am asking for this feature is because my use case is probably a bit different than the typical IT usage where you are monitoring internal and cloud based systems for which only a few stakeholders are responsible. In my case the monitored devices are spread out across many sites in clients homes. If the device is down it is probably due to an internet or power issue which needs to be resolved by the contact on site. That is why I would prefer that the emails go directly to the one responsible for it. The way it is setup now, to accomplish this I need to setup a notification with all of the SMTP info for each recipient even though they are only monitoring a single device. I hope that helps. While this might not be the most common use case I don't think it is so fringe. The way it is setup now assumes that notifications will only be going out to a few people, but sometimes even with one organization the person being notified may only need to know about the uptime of 1 or 2 entities. That is why I am suggesting that the credentials for authentication be stored separately from the intended recipient. So this would apply to phone numbers, emails addresses, handles etc. To preserve current functionality perhaps the currently configured recipient can be configured as the default recipient unless a different one is specified with the monitored entity.