I am still catching up on sleep lost during the amazing Checkmk Conference #11, yet we are already delving into 2.5 topics.
Currently, we are investigating the “Activate Changes” feature and ways to reduce friction when working with it. With this in mind, we have created two new interface concepts and would love to hear your feedback!
One of the time consuming/annoying parts with “activate changes” is getting back to where you’ve been before activating the changes if you forget to open it in a new tab.
Imagine filtering a view, clicking then on the activate changes button - wherever it is located - now activating and want to go back to your previews, filtered view
The concept looks interesting; I like having more information there. But please keep those of us in mind that have tens of sites (~70 in our case), and making the activation page be three times as long would not be that nice. Thanks!
I always check to see if there are any users logged in before I activate changes. If there are users then I have to notify them or defer the activation.
If the activate changes page or flyout could show me the number of users online or who is online, then it will save me the clicks of having to jump to the users page and back.
Why? I have systems with around 100 users - that would result in notifications to too many users every time we have to do something. Also how do you handle than automatic activation from DCD or API actions?
I’m not asking for any automatic notifications to be sent. This is more of a convenience for me to decide when and if I should activate. In my small org, we like to see changes be visible as soon as possible.
I’m sure in large, complex, or multi-tenant environments, where a more controlled/schedule change procedure is preferred, there would be no need for such a feature as the users already expect it based on the routine. Those orgs likely have access to lightning-fast activations via CEE as well, but I’m on CRE so I don’t have the luxury of flying under the radar.
I don’t use DCD (not eligible) or the API, so no concern there for me. In submitting my request for consideration, I would hope that the product team can consider all use-cases, both big and small, for raw and enterprise.
Thank you so much for the overwhelming participation of 168 responses
In the upcoming days, I will analyze the survey and will share the results soon(-ish)
More important to me than the position of the icon would be the ability to activate only my own changes. I don’t know what changes other users are making, or whether they have already completed them or are still in the process of making them.
No, I don’t need to see who is online on the activation page or flyout. I think that would make the interface really clogged, especially for large environments.
A simple count would be sufficient (e.g. Online Users: 3). The number displayed could then be a link to the users page where one could go if they needed to see who is online.
Sorry, not able to react so quick on such important topics, not only that I was on vacation.
Pls. keep in mind that we manage ~300 remote sites with ~1500 admins.
Even more important to us would be to see some details about the timing each step in activations changes take to better be able to drill down any activation timeouts.
As far as I understand we have these steps:
pack the snapshot
transport snapshot to remote site
unpack snapshot
3.1 cmk-update-config in case master has different version than remote
update/compile new configuration and activate
We frequently see timeouts on various remote sites but its hard to determine where the problem comes from. Is it because of WAN speed ( Step 2) or is it because slow VM of remote site (Step 3 and/or Step4) or is it because of inefficient rule set (Step 3.2 and/or Step 4).
So it would be very helpful to show how long each step lasts.
@LaSoe ohh I know what you mean! Unfortunately, this is not in scope for this project, as we are focusing on the discoverability of the “Activate changes”
@mike1098 basically the same. I totally understand and feel that problem, but it is out of scope We had to make the cut somewhere
That being said, we know that there is much to improve in “Activate changes”. Look at this project as the first step of many of improving such a crucial feature
We know there’s much to improve in ‘Activate changes,’ but we had to make the cut somewhere.
The ability to activate or revert specific changes would significantly reduce workflow disruptions by minimising errors and processing delays. Improving the placement of the “Activate Changes” button would also be helpful — I recently forgot to activate my changes, which led to some confusion. A more prominent placement might have prevented such a basic oversight.
If I could prioritise, I’d choose the option to activate specific changes, as this would directly address a recurring challenge in my daily work. While improving the button’s placement is useful, it doesn’t address an issue that actively hinders me in my day-to-day tasks.
But if we stick to GUI improvements — in my opinion, there is too much focus on assisting inexperienced users to facilitate their initial interactions. However, after a short time, they too are confronted with the long-standing problems in their daily work that I —and others— have been dealing with for years.
I would like to highlight only a few long-awaited improvements that, in my opinion, would significantly enhance day-to-day work in the GUI, going beyond merely repositioning the activation button:
you’re right; I asked for it, and I’m honestly so glad we always receive so much feedback. I’m also glad you’re open about the problems you’re facing instead of suffering in silence. When I look through the list of ideas you posted, I agree with all of them, especially the multi-select dropdown.
For the initiative I’m working on, we’re focusing on the initial steps with Checkmk. Initially, I assumed we could add a folder hierarchy, rework the “Service Monitoring Rules” page (it makes me cry every time I open it), and finally get rid of “Show More” and “Show Less.” Then, we ran a usability test with Sys Admins and DevOps who had never used Checkmk before. It was horrifying to watch. They never got around to creating a rule. The problems started at the beginning, when they failed to find and install the agent. Then, they didn’t realize that they had to activate changes to see them in the monitoring. So, before looking at working with folders or rules, we (my dev team and I) needed to work on answering these questions:
How can we improve the workflow for first time users to successfully add a host including installing an agent?
How can we make sure that users can easily activate changes even when they don’t know that this concept exists?
I will go into more details during the community call on 1st of July, so if you are interested, please join
Also, I really want to emphasize I appreciate all the comments, feedback and challenges, because we are doing the whole thing for you, our users. It’s great to know that you care and that what we are doing is important to you. Motivates me a lot
(Survey is closed) Click on this link to start the survey. 
We had to make the cut somewhere
without any benefit.