Deprecation of the Service Tags feature

Dear Checkmk community,

We are announcing the deprecation of the Service Tags feature in Checkmk 2.2. The removal will happen with the Checkmk 2.3 release. This feature has been in Checkmk since Checkmk 1.6, but never got a relevant adoption due to the also introduced feature Service Label, which offers a higher flexibility.

We understand that this feature was useful for some users, and we apologize for any inconvenience this may cause. We are committed to providing the best experience for our users, and we believe that this change will help us to do that.

If you use the feature heavily or have dedicated workflows depending on this feature, please send me a direct message here in the forum and I will reach out to you.

Why does tribe29 deprecate features in Checkmk
There are a number of reasons why it might make sense to deprecate a feature in a software product:

  • A feature may be outdated or superseded by a newer, better feature
  • A feature is no longer being actively used or has not got the adoption initially expected
  • Deprecating a feature can help to simplify the Checkmk codebase and make it easier to understand and maintain
  • Deprecating a feature can help to improve the overall Checkmk user experience by eliminating confusing or unnecessary functionality

Thank you for your understanding and continued support.

The Checkmk product team

That’s disappointing.

TAGS got the advantage of being defined fix and not like attributes and service labels which can be defined free. TAGS can be chosen out of predefined list so you can be sure it is working and is is always the same.

Furthermore “service labels” cannot be chosen in views - you can only see all labels in a column added to that service and not just certain one. I am not sure if service attributes (which could be chosen in views) are doing better than service tags and can be used same way.

Maybe the reason that not many (if that is even the case) were not using it is that it was imho still in “beta”. If it would have been implemented same like HOST TAGS, then probably more would have used it.


We regret that Tribe29 never wanted to understand the benefits of Service Tags and implemented them only half-heartedly. Since the service tags were never fully implemented, their full potential could of course never be fully exploited. For example, as condition in rules, as has always been the case with host tags.

We’ve had several conversations with Tribe29 regarding the added value of service tags, but the conversations always ended with the reasoning that we can use labels now and no one uses the service tags (which is obvious if you don’t implement them properly).

One of the biggest advantages of the service tags over the labels is that they are predefined and therefore much less error prone. Also, you can for example search/filter for “empty” tags or “tags that don’t contain” and use them in views which is not possible with the labels. If the Service Tags would have been implemented completely, they could have also been grouped as Auxiliary Tags.

We use as one example the tags for billing and there it would be very unfavorable if you have wrong or incomplete values in the tags.


If you think that service tags are useful and therefore should be fully implemented instead of expanded:

This is very disappointing and as there has just been a discussion regarding service tags Default Service Tag cannot be set. It leaves some kind of a bitter taste that you, tribe29, did not answer anymore to the topic and roughly one month after their last (not satisfying) answer decided to deprecate this feature. You say that this feature never got relevant adoption. How do you know that? When looking at our setup, tribe29 knows pretty much nothing about it. Or are you collecting usage metrics? If so, we and probably others would have a compliance issue. And even if this is true: Instead of just deprecating it, why did you not ask yourself the question why this is the case?
What is next? Deprecating Host Tags as well because there are host labels?
I strongly encourage you to ask your (paying) customers in advance instead of just deprecating things. In many, if not most, cases there is a reason why customers use option a) and not b). Just speak with them and understand their needs. It is pretty obvious that you as a software developer can not know many (complicated and/or heterogeneous) real world setups. So please listen to your customers. Because real world scenarios are different to labs.


Checkmk sites are not sending stuff to tribe29 except if you decide to do so for the license audit, which can also be done offline.

Additionally, we are in fact talking to customers and partners about deprecation plans in advance.
Obviously we can not ask every single customer for their distinct use case.
But we do never make those decisions lighthearted or ungrounded.

Well you said “no relevant adoption”. What is relevant? 40%? 60%? Of course you can not talk to every single customer. But I doubt that you talked to a “relevant” number of customers about that.
And there is no official mailing to customers about the deprecation, just an announcement here in the forum. How many customers do visit the forum regulary?
And to be honest: When looking at the thread I mentioned before, this descition sounds pretty lighthearted to me.
And please answer this question: Why do you deprecate service tags but not host tags? And that doesn’t mean, that I want you to deprectate host tags!


Another very good point! @martin.hirschvogel and @Sara
I agree, this should be an E-Mail announcement to all your paying customers. Like this, many will just notice by coinsidence or even confronted when upgrading and hopefully testing before. Imagine you created a lot with the service tags (can be any feature) and even your billing relys on it - boom!

Would also match and should be attached to this topic too

Thank you all for your feedback. Let me clarify some details discussed in the replies above in more details:

We do not take any decision to deprecate a feature lightly. Before making this announcement, we checked with our Checkmk consultants and our top partners, if they are aware of any usage of this feature. The feedback was a clear no.

As the next step in the process of deprecating a feature, we placed this announcement, which will be referenced in the next Checkmk newsletter. This should help to reach more customers. I asked for a direct message if this is an issue for any of our customers. While I haven’t got any direct message, I notice 3 customers having issues with the deprecation as they left comments under the announcement.

Since the newsletter is not yet sent, I monitor the forum for more comments.

As Martin mentioned, Checkmk currently does not have any feature to collect product telemetry. Therefore, forum posts and newsletters are the only way to get feedback. But this is something we should consider for the future.

Ok, so if a customer neither has a contract with a “top partner” nor uses consulting, he has no voice. No matter if he licensed a 6 digit number of checks in the highest edition (cme). Wow, interesting to read.
I guess most tribe29 customers are german companies. So IMHO collecting telemetry is not a very good idea. Instead of this, you should make surveys and give every (paying) customer a voice.
Apart from this: Have you asked your proxied customers why they don’t use the feature? The chance is high that they don’t use this because the implementation is pretty incomplete.

1 Like


There should be a dedicated way (i.e. special EMail address) for important notifications. I do not read every newsletter. There are too many and I can easily oversee the one from Tribe.


Rephrasing what Thomas said: The post here is your chance to make your voice heard, if you are using this feature. It’s a way for us to test the waters as well. F.e. in the Deprecation of the Favorites feature thread, we see that no one actually seems to care about the feature.
And, we use our top partners and our consultants as a proxy as it is not viable for us to reach out manually to 3000+ customers. To facilitate open exchange and discuss topics like this, we build this forum (instead of the old mailing list, which some might remember) as well.

If you use the feature heavily or have dedicated workflows depending on this feature, please send me a direct message here in the forum and I will reach out to you.

Thus, please use the chance and send Thomas a message. It gives us then the chance to go into a 1-on-1 discussion with you to better understand why and how you use the feature, and helps us to decide how to move forward with this.

To shine some history on the feature: When we added cloud monitoring in Checkmk 1.6, we wondered how to best integrate “labels”, which are a key element to cloud services. As we already had host tags, we thought why not reuse this concept and introduce service tags. Quickly we realized, this is not the right path due to the required flexibility, thus we introduced host and service labels. What we should have done back then was to immediately remove the commit with the service tags. That’s why you also don’t see a big werk announcing the service tags and any comment on service tags in the documentation. (@LaMi please correct me if I am wrong as I just joined the company back then)

The crucial part about tags vs labels is: Tags are predefined. Labels are freeform.
This makes a huge difference when many people from different teams are working with a system.
Also in views, if service tags would be implemented the same way as host tags, the view would only show the selected tags. When using labels, every label is displayed, which is unusable when a service has many labels
Also searching labels sometimes takes very long. But this could also be specific to our setup.

1 Like

But this actually matches with the QA Problem (@Sara for the dev thread)
“Yes we testet it, of course, we also run this version in a hand full of Production Environments we have access too”
Good that we have this amazing, and obviously hetorogen production environments for testing, cant imagine how much higher the number of bugs would be without them :face_with_open_eyes_and_hand_over_mouth: (right now around 550! :exploding_head: bug/sec fixes with p19)

Does it also imply that you dont check your tickets and feedback emails regarding desicions this?
As I’m 100% sure you will find some mentioning about it and not only from one customer

Not a partner, but with more then a couple of dozens of customers and some of the biggest companys in our country, nobody asked us as well :roll_eyes:
But this is really alarming if its the same case like QA. Ask a couple of Partners and Customers and if they dont have a case, thats it, especially if you know the number of usecases are limited due to incomplete implementation, as @gk998 mentioned as well

First of all, I would like to thank Tribe29 for the open discussion here. It takes some backbone to expose yourself to public criticism and deserves our thanks and respect.

The feedback here and the 20+ votes clearly show that your (paying) customers prefer to keep this Feature. The service tag feature request has already received more votes than the many of the cloud related feature requests.

I hope you can embrace the feedback from your customers and improve this great feature by adding the so long missed functions instead of removing the service tags. So that Checkmk continues to be this great tool that we all love so much.


On my distributed monitoring set up I am using Host Tags extensively.
I have around 2000 Tags that are controlling many rules and views. And having them predefined helps putting asset numbers and serial numbers on hosts. Tags can also be used to define locations, customers, rooms, contacts, warranties, system functions etc…

We even wrote software that synchronizes the host tags using the REST API of Checkmk with our ticketing system. Additionally, we use the tags together with dynamic host information from agents and snmp to automatically create offline documentations of hosts with a template.

Having the Tags stripped away would leave my setup totally unusuable. If the Tags are removed in future versions, I won’t update.

Don’t worry. This is about the service tags, not host tags.

1 Like

Thanks for clearing this up, I misunderstood the feature that was being deprecated.

We want to thank you for your feedback. We have decided to NOT deprecate Service Tags in Checkmk 2.2.

What does this mean going forward?
While we recognize the use cases for Service Tags in their current state, our focus will remain on expanding the functionality of host- and service labels. This is where we see more demand from a broader customer base. For example, we are currently working on supporting using AND / OR / NOT operations on labels in filters and are evaluating if it is feasible to extend this to rules as well.

In the spirit of transparency and managing expectations: this means that in the near future we do not plan to dedicate development resources towards expanding the functionality of service tags. If you feel different about the priority of service tags, please feel free to vote on the feature request by LaSoe.