Autumn is fast approaching, and we have a brand new Micro Survey we need your insights on:
Checkmk has many built-in views, graphs, dashboards, and sidebar elements to give you a better overview. But we know that every IT environment is different and there is no one-size-fits-all solution. That’s why it’s possible to customize them! With this Micro survey, we want to take a closer look at the customization options in Checkmk.
Click here to start the survey
We look forward to hearing your answers!
Last month we asked you about date and time formats. We found that most of you prefer YYYY-MM-DD because it is easy to sort and complies with ISO standards.
Read all about the results here.
----- Survey has been closed -----
The 8th Micro Survey is now closed. We appreciate everyone who took the time to share their thoughts and insights on the use of Checkmk. Thank you for your valuable input and stay tuned for updates on our progress!
Thanks everyone for participating in this Micro survey! We asked you about customization in Checkmk and the behavior you expect when cloning a built-in view.
Dashboards (86%) and Views (84%) are the elements that are most often customized, followed by Sidebar elements (54%) and Graphs (49%). Only 4% of all respondents have not customized anything.
Whether cloning a built-in view should override the built-in view is a controversial subject, although 78% of respondents said they usually use a built-in view as a starting point rather than to override it.
Reasons for overriding the built-in view include the ability to update a view without changing the link/location, which makes distribution easier. On the other hand, some respondents state that cloning should never mean overriding.
Currently, when you click on the ‘clone’ icon of the built-in view, you create a copy that is displayed instead of the original view. A “real” copy/clone is only created when you change the ID. This can result in accidental overrides and the results of the Micro survey indicate that this current behavior is not intuitive for everyone. So we’re currently looking at ways to prevent accidental overrides without taking away the ability to override. I will update this thread as it becomes more specific.
That said, we see that this is only part of the problem, as there is currently a lack of transparency about which built-in views are overridden by which. This is also something we want to improve in the future.