starred/uptime-kuma

Fork 0

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

Select monitors for maintenance windows by `AND`-ing Tags #2157

New issue

Open

opened 2026-02-28 02:44:52 -05:00 by deekerman · 10 comments

deekerman commented

2026-02-28 02:44:52 -05:00

Owner

Originally created by @gardium90 on GitHub (May 3, 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

Enable the use of tags in maintenance window configurations in addition to specific monitor selection.
Allow a combination of tags for flexibility (e.g., platform/service and environment).
When selecting tags, ensure an 'all-inclusive match' (all tags must be matched), to define monitors as selected for a maintenance window.

If the new monitor had the appropriate set of tags with this new feature, it would then automatically be picked up by the maintenance window config.

✔️ Solution

Implement a tagging system where users can group monitors with relevant tags (e.g., services Foo, Bar, and environments Dev, Prod) Depending on the type of maintenance/issues, it may affect any combination of these services and environments.
By grouping together the necessary tags, e.g. A => A's environments, or Prod => Prod systems, or a combination, say Foo + Dev, then the maintenance window knows which monitors to deactivate during the maintenance window, without having to select specific monitors.

❓ Alternatives

It would already help, to see the tags assigned to a monitor in the 'affected monitors' dropdown, but I'm not sure if this is more cumbersome to also have a good UI for this,

📝 Additional Context

The issue was reworked to be clearer/less wordy by @CommanderStorm. Please refer to the issue history for the original post.

Originally created by @gardium90 on GitHub (May 3, 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 Enable the use of tags in maintenance window configurations in addition to specific monitor selection. Allow a combination of tags for flexibility (e.g., platform/service and environment). When selecting tags, ensure an 'all-inclusive match' (all tags must be matched), to define monitors as selected for a maintenance window. If the new monitor had the appropriate set of tags with this new feature, it would then automatically be picked up by the maintenance window config. ### ✔️ Solution Implement a tagging system where users can group monitors with relevant tags (e.g., services `Foo`, `Bar`, and environments `Dev`, `Prod`) Depending on the type of maintenance/issues, it may affect any combination of these services and environments. By grouping together the necessary tags, e.g. `A` => `A`'s environments, or `Prod` => `Prod` systems, or a combination, say `Foo` + `Dev`, then the maintenance window knows which monitors to deactivate during the maintenance window, without having to select specific monitors. ### ❓ Alternatives It would already help, to see the tags assigned to a monitor in the 'affected monitors' dropdown, but I'm not sure if this is more cumbersome to also have a good UI for this, ### 📝 Additional Context The issue was reworked to be clearer/less wordy by @CommanderStorm. Please refer to the issue history for the original post.

deekerman added the

feature-request

A:maintenance

labels

2026-02-28 02:44:52 -05:00

deekerman commented

2026-02-28 02:44:56 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 1, 2023):

Is this a duplicate of #2457?
If no, please edit your feature request to make it more distinct and/or how the change you want builds upon the linked issue.
If yes, please close this issue (duplicate issues just makes managing issues harder)

@CommanderStorm commented on GitHub (Jun 1, 2023): Is this a duplicate of #2457? If no, please edit your feature request to make it more distinct and/or how the change you want builds upon the linked issue. If yes, please close this issue (duplicate issues just makes managing issues harder)

deekerman commented

2026-02-28 02:44:56 -05:00

Author

Owner

@gardium90 commented on GitHub (Jun 1, 2023):

Apologies. I didn't find this feature request while searching keywords in the Issue Tracker.

However, after reading that feature request, there is a major differences in my opinion that I already address in my request, plus in terms of functionality and 'description' of what I want to achieve, my feature request is more specific.

The major difference I see, is that they request "[...] all monitors with any of the tags selected, will be added to the maintenance windows". I specify in this request I'd like an 'all-inclusive match', due to multi instance tagging AND service tagging.

I hope this clarifies, but if you disagree to my point then please let me know and I'll close the request.

Thank you, and have a nice day.

@gardium90 commented on GitHub (Jun 1, 2023): Apologies. I didn't find this feature request while searching keywords in the Issue Tracker. However, after reading that feature request, there is a major differences in my opinion that I already address in my request, plus in terms of functionality and 'description' of what I want to achieve, my feature request is more specific. The major difference I see, is that they request "[...] all monitors with any of the tags selected, will be added to the maintenance windows". I specify in this request I'd like an 'all-inclusive match', due to multi instance tagging AND service tagging. I hope this clarifies, but if you disagree to my point then please let me know and I'll close the request. Thank you, and have a nice day.

deekerman commented

2026-02-28 02:44:56 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Jun 1, 2023):

The reason I like the other issue more is, that it is more concise, readable, older and more liked (we use 👍🏻 to prioritise work).

I don't understand what you mean by “all-inclusive match”. What do you mean?

The major difference I see, is that they request "[...] all monitors with any of the tags selected, will be added to the maintenance windows". I specify in this request I'd like an 'all-inclusive match', due to multi instance tagging AND service tagging.

Could this not be integrated into the issue @peschmae created?

@CommanderStorm commented on GitHub (Jun 1, 2023): The reason I like the other issue more is, that it is more concise, readable, older and more liked ([we use 👍🏻 to prioritise work](https://github.com/TUM-Dev/Campus-Android/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc)). I don't understand what you mean by “all-inclusive match”. What do you mean? > The major difference I see, is that they request "[...] all monitors with any of the tags selected, will be added to the maintenance windows". I specify in this request I'd like an 'all-inclusive match', due to multi instance tagging AND service tagging. Could this not be integrated into the issue @peschmae created?

deekerman commented

2026-02-28 02:44:56 -05:00

Author

Owner

@peschmae commented on GitHub (Jun 1, 2023):

I think adding a toggle to switch between - and / or matching for the selected tags shouldn't be too much of an issue.

I can easily add this to my proposal

@peschmae commented on GitHub (Jun 1, 2023): I think adding a toggle to switch between - `and` / `or` matching for the selected tags shouldn't be too much of an issue. I can easily add this to my proposal

deekerman commented

2026-02-28 02:44:57 -05:00

Author

Owner

@CommanderStorm commented on GitHub (Dec 8, 2023):

@gardium90
I have reworded the issue to make the content more clear what you are requesting.

@CommanderStorm commented on GitHub (Dec 8, 2023): @gardium90 I have reworded the issue to make the content more clear what you are requesting.

deekerman commented

2026-02-28 02:44:57 -05:00

Author

Owner

@gardium90 commented on GitHub (Dec 11, 2023):

@CommanderStorm Hello, sorry I didn't have time to respond to your comment from 2 days ago. I thought this request was put to inactive as part of being consolidated with @peschmae 's proposal.

I believe upon reviewing your changes to the request, you seem to have understood what I meant. Service and instance seem to be reflected correctly, and my wish was the appropriate "and-ing of tags" as you have clarified now. I still see a reason to have "or-ing" as well, so however you chose to consolidate the requests I'll just be happy if this feature makes in into a upstream release.

Thank you again for the consideration, have a merry festive season!

@gardium90 commented on GitHub (Dec 11, 2023): @CommanderStorm Hello, sorry I didn't have time to respond to your comment from 2 days ago. I thought this request was put to inactive as part of being consolidated with @peschmae 's proposal. I believe upon reviewing your changes to the request, you seem to have understood what I meant. Service and instance seem to be reflected correctly, and my wish was the appropriate "and-ing of tags" as you have clarified now. I still see a reason to have "or-ing" as well, so however you chose to consolidate the requests I'll just be happy if this feature makes in into a upstream release. Thank you again for the consideration, have a merry festive season!

deekerman commented

2026-02-28 02:44:57 -05:00

Author

Owner

@sevmonster commented on GitHub (Dec 16, 2023):

Yes, as someone that uses tags for tons of services, sometimes they intersect. For example, if I will be performing maintenance on Docker on a specific host, then I would want monitors with the host1 AND docker tags to be included. But if I am taking down two different hosts for maintenance, I would want monitors host1 OR host2 to be included.

The fact that there is no capability of using tags for maintenance makes the feature excessively cumbersome for users with a lot of monitors (like me), to the point where I do not use it due to the extra administrative overhead.

Specifically, when adding or modifying a new service that should be affected by update windows, you must find and update said maintenance configurations one at a time. But when using tags, all you have to do is add/remove tags and have the maintenance config query the tags dynamically.

@sevmonster commented on GitHub (Dec 16, 2023): Yes, as someone that uses tags for tons of services, sometimes they intersect. For example, if I will be performing maintenance on Docker on a specific host, then I would want monitors with the `host1` *AND* `docker` tags to be included. But if I am taking down two different hosts for maintenance, I would want monitors `host1` *OR* `host2` to be included. The fact that there is no capability of using tags for maintenance makes the feature excessively cumbersome for users with a lot of monitors (like me), to the point where I do not use it due to the extra administrative overhead. Specifically, when adding or modifying a new service that should be affected by update windows, you must find and update said maintenance configurations one at a time. But when using tags, all you have to do is add/remove tags and have the maintenance config query the tags dynamically.

deekerman commented

2026-02-28 02:44:57 -05:00

Author

Owner

@bmbvenom commented on GitHub (May 21, 2025):

Hello, it's a year and half later and I was just wondering if there has been any progress on this. If not in v1 maybe in v2?

Thank you for all your work on this great project!

@bmbvenom commented on GitHub (May 21, 2025): Hello, it's a year and half later and I was just wondering if there has been any progress on this. If not in v1 maybe in v2? Thank you for all your work on this great project!

deekerman commented

2026-02-28 02:44:57 -05:00

Author

Owner

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

Nobody has done work on this to our knowlege.
It is also not on my cutting block of issues I want to implement => feel free to implement it.

If the UX is close to the rest and does not incurr masssive overhead for the workflow this would be something I would merge.

@CommanderStorm commented on GitHub (May 21, 2025): Nobody has done work on this to our knowlege. It is also not on my cutting block of issues I want to implement => feel free to implement it. If the UX is close to the rest and does not incurr masssive overhead for the workflow this would be something I would merge.

deekerman commented

2026-02-28 02:44:57 -05:00

Author

Owner

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

Also, this issue does not need to be in v2.0 I don't see any possibility for breakage.

@CommanderStorm commented on GitHub (May 21, 2025): Also, this issue does not need to be in v2.0 I don't see any possibility for breakage.