Ability to blanket disable a notification method #3945

Open
opened 2026-02-28 03:46:02 -05:00 by deekerman · 2 comments
Owner

Originally created by @orangehand on GitHub (Feb 1, 2025).

x

🏷️ Feature Request Type

Settings

🔖 Feature description

Please add a method in the settings>notification to blanket disable a method across all existing monitors. Maybe unless it is the only one being used?
Thanks

✔️ Solution

x

Alternatives

No response

📝 Additional Context

No response

Originally created by @orangehand on GitHub (Feb 1, 2025). ### 📑 I have found these related issues/pull requests x ### 🏷️ Feature Request Type Settings ### 🔖 Feature description Please add a method in the settings>notification to blanket disable a method across all existing monitors. Maybe unless it is the only one being used? Thanks ### ✔️ Solution x ### ❓ Alternatives _No response_ ### 📝 Additional Context _No response_
Author
Owner

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

Could you explain the workflow where this would assist you?

In my mind, you either want to

  • permantly not get a notification from a notification provider => delete it
  • temporarily not get notifications from a notification provider => enact a maintenance
@CommanderStorm commented on GitHub (Apr 17, 2025): Could you explain the workflow where this would assist you? In my mind, you either want to - permantly not get a notification from a notification provider => delete it - temporarily not get notifications from a notification provider => enact a maintenance
Author
Owner

@husjon commented on GitHub (Jan 29, 2026):

Recently I started looking thinking about this myself for my own instance as I'm in the process of switching from one provider to another.

For me at least, I'm thinking the following scenario:
Assume we have an Uptime Kuma instance with 2 existing notification providers set up (e.g. Telegram and Slack)
We'd like to replace one of them for another (e.g. Telegram for Signal)
We'd like to have a test-period where all 3 are up, and after some time another test-period where we disable the one mentioned above while retaining the configuration so that in case it should cause issues, it can be re-enabled, then finally if all is working as expected the notification provider can be disabled.

Since there is already a Apply on all existing monitors, being able to Apply the disabled state to all existing would be a nice addition.
Image

Alternatively, adding an Enabled state to the notification provider itself where if it is disabled, the notification provider is not acted upon at all when a monitor changes state and is not listed in the monitors notifications list.
Image

Hope this makes sense.

@husjon commented on GitHub (Jan 29, 2026): Recently I started looking thinking about this myself for my own instance as I'm in the process of switching from one provider to another. For me at least, I'm thinking the following scenario: Assume we have an Uptime Kuma instance with 2 existing notification providers set up (e.g. Telegram and Slack) We'd like to replace one of them for another (e.g. Telegram for Signal) We'd like to have a test-period where all 3 are up, and after some time another test-period where we disable the one mentioned above while retaining the configuration so that in case it should cause issues, it can be re-enabled, then finally if all is working as expected the notification provider can be disabled. Since there is already a **Apply on all existing monitors**, being able to Apply the disabled state to all existing would be a nice addition. <img width="485" height="153" alt="Image" src="https://github.com/user-attachments/assets/78d394f3-933c-4f94-933e-3e161495606b" /> Alternatively, adding an Enabled state to the notification provider itself where if it is disabled, the notification provider is not acted upon at all when a monitor changes state and is not listed in the monitors notifications list. <img width="233" height="205" alt="Image" src="https://github.com/user-attachments/assets/414e19c5-1e78-4418-8a18-4a16866e8334" /> Hope this makes sense.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/uptime-kuma#3945
No description provided.