Modern apps are built by many teams, each owning a different set of services: APIs, background jobs, databases, platform components, and more. As the system grows, it gets harder for each team to focus on what actually matters to them.When everything is mixed together, dashboards get messy, service maps are too large to be useful, and alerts end up reaching the wrong people. Instead of helping, your observability stack turns into a distraction. It has lots of data, but no clear context.
To fix that, observability needs to reflect how your teams actually work. We need a way to group services so that each team sees only what they’re responsible for.Kubernetes namespaces might seem like a solution, but they don’t always map cleanly to team ownership. Teams often work across multiple namespaces, share them with others, or need to include services that don’t run in Kubernetes at all.
That’s why we introduced application categories in Coroot. They let you group services by app name, namespace (when available), or with annotations in your Kubernetes manifests. This way, the mapping lives right in Git, alongside your deployment specs.
To define a category for a Kubernetes application (like a Deployment, StatefulSet, DaemonSet, or CronJob), just add an annotation like this:
apiVersion: apps/v1
kind: Deployment
metadata:
name: some-app
namespace: default
annotations:
coroot.com/application-category: payments
You can also use Pod annotations if needed. This makes it easy to keep your app-to-category mapping version-controlled and close to your deployment logic.
For non-Kubernetes applications, or when annotations aren’t an option, you can define categories manually using pattern-based configuration. Each category is defined by a set of glob patterns in the format namespace/application_name
Keep in mind: if an application has both a matching pattern and an annotation, the annotation takes precedence.
So, now that you’ve grouped your services — how do you actually use that in Coroot?
Categories aren’t strict boundaries. Think of them more like tags you can use to filter things. In the service map or app health view, you can see multiple categories at once, hide the ones you don’t care about, or focus on just your team’s apps.
They’re also used for RBAC (Role-Based Access Control), so you can give each team access only to the apps they own.
And the latest feature in Coroot is alert routing by application categories. You can send alerts for each category to the right Slack channel or PagerDuty service, so teams don’t have to scroll through a noisy alert stream trying to spot the ones that matter. It seriously cuts down on alert fatigue and helps everyone stay focused on their own stuff.
Coroot also automatically monitors Kubernetes rollouts. It checks rollout status, detects issues like stuck deployments, compares the performance of the new version with the previous one, and notifies the right team if something goes wrong. And yes, you can disable these notifications for specific categories or route them to a dedicated Slack channel, or any other notification method you use.
Conclusion
Application categories in Coroot bring structure to your observability setup by aligning it with how your teams actually work. Instead of throwing everything into one big pile, you can give each team a focused view of the services they own — and nothing else.
It’s a simple way to cut through the noise and keep things clear, even as your system grows.
Try Coroot to enable team-oriented observability and bring full visibility to your services.
Use the Coroot Community Edition for free, or start a free trial of Coroot Enterprise Edition for advanced features.
If you like Coroot, give us a ⭐ on GitHub.
Questions or feedback? Join us on Slack.
