[Feature Request] Add option to select different notifications for `DOWN` and `UP` #3115

New issue

Closed

opened 2026-02-28 03:18:34 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-28 03:18:34 -05:00

Owner

Originally created by @mh166 on GitHub (Feb 9, 2024).

🏷️ Feature Request Type

Settings

🔖 Feature description

It should be possible to optionally select a different notification for the UP message.

Use cases:

It can be useful to inform different groups for DOWN or UP events respectively.
It will allow (depending on the notification used) to have different message templates.
It will allow to have different sounds and/or priorities tied to those notifications.

✔️ Solution

A toggle switch "Use different notification for UP message" should be added to the notification settings of each monitor. If enabled, the notification methods select above would only be used for DOWN messages.
Below this toggle, it should display all the notification methods again, for use with UP messages.
If no notification provider is selected, Uptime Kuma will only inform about DOWN events and omit information about changes back to UP status.
- A short message making the user aware of this behaviour may or may not be displayed.

❓ Alternatives

Alternatives to the UI changes suggested above:
- Instead it would be possible to add a toggle switch _"Use different notifications for DOWN and UP messages above the list of notification providers.
- The list of notification providers could then be displayed as a table like so:

Notification	Use for `DOWN`	Use for `UP`
Provider 1	[x]	[ ]
Provider 2	[ ]	[x]
Provider 3	[x]	[x]

Alternatives to this implementation in general
- #1953, #1582 and #4203 talk about implementing state-depending notification settings per provider
- I think this will lead to a lot of duplicated code and incoherent behaviour (some notification providers may implement such change, others may not)

📝 Additional Context

The idea behind all of this is that I want to hear an alarm and have a different vibration pattern for the notifications on my phone depending on wether a service goes down or comes back up. I want to be sure to receive the DOWN notification, but I don't care if only way later I see that the service is UP again.

Therefore, I would add the same notification provider twice (e.g. Telegram and Ntfy in my case). The one named "Ntfy - UP", for example, would just receive Priority 3 or 4 (medium / high). Then I'd add another instance of this provider, call it "Ntfy - DOWN" and set the priority to 5 (max). I can then configure my phone to treat those messages in a certain way.

This general approach using the monitor settings instead of making changes to the notification provider itself would allow for a more flexible and fine-grained approach, as one could use it with every notification provider available and mix and match as required.

// Edit: found more duplicates

Originally created by @mh166 on GitHub (Feb 9, 2024). ### 📑 I have found these related issues/pull requests - #1953 - #1582 - #508 - #1233 - #2925 - #4203 ### 🏷️ Feature Request Type Settings ### 🔖 Feature description It should be possible to optionally select a different notification for the `UP` message. Use cases: - It can be useful to inform different groups for `DOWN` or `UP` events respectively. - It will allow (depending on the notification used) to have different message templates. - It will allow to have different sounds and/or priorities tied to those notifications. ### ✔️ Solution - A toggle switch _"Use different notification for `UP` message"_ should be added to the notification settings of each monitor. If enabled, the notification methods select above would only be used for `DOWN` messages. - Below this toggle, it should display all the notification methods again, for use with `UP` messages. - If no notification provider is selected, Uptime Kuma will only inform about `DOWN` events and omit information about changes back to `UP` status. - A short message making the user aware of this behaviour may or may not be displayed. ### ❓ Alternatives - Alternatives to the UI changes suggested above: - Instead it would be possible to add a toggle switch _"Use different notifications for `DOWN` and `UP` messages above the list of notification providers. - The list of notification providers could then be displayed as a table like so: | Notification | Use for `DOWN` | Use for `UP` | | --- | --- | --- | | Provider 1 | [x] | [ ] | | Provider 2 | [ ] | [x] | | Provider 3 | [x] | [x] | - Alternatives to this implementation in general - #1953, #1582 and #4203 talk about implementing state-depending notification settings _per provider_ - I think this will lead to a lot of duplicated code and incoherent behaviour (some notification providers may implement such change, others may not) ### 📝 Additional Context The idea behind all of this is that I want to hear an alarm and have a different vibration pattern for the notifications on my phone depending on wether a service goes down or comes back up. I want to be sure to receive the `DOWN` notification, but I don't care if only way later I see that the service is `UP` again. Therefore, I would add the same notification provider twice (e.g. Telegram and Ntfy in my case). The one named "Ntfy - UP", for example, would just receive Priority 3 or 4 (medium / high). Then I'd add another instance of this provider, call it "Ntfy - DOWN" and set the priority to 5 (max). I can then configure my phone to treat those messages in a certain way. This general approach using the monitor settings instead of making changes to the notification provider itself would allow for a more flexible and fine-grained approach, as one could use it with _every_ notification provider available and mix and match as required. // Edit: found more duplicates

deekerman

2026-02-28 03:18:34 -05:00

closed this issue
added the
feature-request

A:notifications
labels

deekerman commented

2026-02-28 03:18:38 -05:00

Author

Owner

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

Duplicate of #508

@CommanderStorm commented on GitHub (Feb 9, 2024): Duplicate of #508

deekerman commented

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

Author

Owner

@mh166 commented on GitHub (Feb 9, 2024):

Sorry, I found the other issue(s) only now (see my edit above) – pretty much at the same time that you were posting. Thanks for your work. 😊

@mh166 commented on GitHub (Feb 9, 2024): Sorry, I found the other issue(s) only now (see my edit above) – pretty much at the same time that you were posting. Thanks for your work. 😊

deekerman commented

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

Author

Owner

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

Have not looked into these, but some may be mergable => will look into this in the evening/weekend

@CommanderStorm commented on GitHub (Feb 9, 2024): Have not looked into these, but some may be mergable => will look into this in the evening/weekend