Grafana Alerting adds separate routing ownership for teams
Grafana Alerting is giving teams a way to manage their own notification routing without editing the configuration used by everyone else. In Grafana’s announcement, Matt Jacobson reports that multiple notification policies are generally available in Grafana 13.2 for Grafana-managed alerting. A notification policy is a set of instructions governing where alerts go and when messages are sent. The change makes those instructions independently manageable, rather than keeping all routing under one shared configuration.
The feature addresses an operational problem familiar to growing IT organisations. A small alerting setup may need only a few contact points, the destinations that receive notifications, and label matchers, conditions that select alerts using attached attributes. As teams and services multiply, that setup can become a shared dependency. Even a minor routing change may require navigating unrelated rules, coordinating ownership and obtaining access to more configuration than a team needs.
Why separate trees matter
Grafana Alerting’s routing model builds on Prometheus Alertmanager, software that handles alert notifications. Traditionally, it uses one global notification policy tree: a top-level route with nested child routes beneath it. Labels, descriptive attributes attached to alerts, determine which routes match. Those routes govern how alerts are collected into groups, notification timing and the contact points that receive messages.
That arrangement suits small or centrally operated systems. At larger scale, every team must fit its logic into the same hierarchy, updates operate on the complete tree and permissions can extend across a configuration much broader than an individual team’s responsibility. Large trees also become harder to understand, review and change safely. Creating branches for payments, platform and security provides logical separation, but those branches still share their lifecycle, provisioning boundary and permissions. Provisioning means creating or updating configuration through a managed process.
Named policies turn those branches into independently managed resources. Each has its own root policy and child routes, while the underlying label-based routing behaviour stays the same. An alert rule, a configured condition that produces alerts, can select a named policy. If a payments rule selects “payments,” its alerts pass only through that policy’s tree. Rules with no named policy selected keep using the default policy, preserving existing behaviour and allowing gradual adoption.
Independent changes and access
According to Grafana, administrators can create, retrieve, update, delete, export and provision an individual named policy without replacing the others. A platform team can deploy its routing changes without also deploying the payments or security configuration. Importantly, Grafana says a change to one tree leaves both the routing configuration and the notification state of alerts assigned to other policies unchanged. That is a specific boundary between policies, not a claim that a mistaken change cannot affect alerts within the policy being edited.
The same separation helps teams using alerting as code, where configuration is stored and deployed through software workflows. A Terraform workspace, an isolated management context in the infrastructure-configuration tool Terraform, or an automated deployment process can own one policy instead of the organisation’s entire routing setup. This aligns the scope of a deployment with the people responsible for reviewing it.
Policy-level role-based access control, permissions assigned through user roles, provides a corresponding ownership boundary. Administrators can determine who may view, create, update or delete individual policies, with permissions managed through the Grafana user interface. Jacobson’s example gives the payments team control of its own policy without permission to change or even view the security policy. A central observability team, responsible for understanding system behaviour through operational signals, can retain the default policy and organisation-wide fallbacks.
Choosing useful boundaries
Grafana suggests dividing policies by team, such as “payments,” “security” or “platform”; by service, such as “checkout-api” or “identity”; or by domain, such as “infrastructure,” “customer-facing” or “data-platform.” Separate environments can also justify separate policies when their routing and ownership differ substantially. The objective is meaningful ownership or lifecycle separation, not necessarily a policy for every alert rule.
Smaller trees let owners review their default destination, escalation paths for bringing in additional responders, grouping and notification timing without searching through other teams’ routes. The transferable lesson is that a visual branch in a shared configuration is not the same as an independent change or permissions boundary. The latter determines who can deploy changes and how widely those changes reach.
How the configuration works
In the interface, the path is Alerts & IRM → Alerting → Notification configuration → Notification policies. Users can create a policy or open an existing tree there, then choose the destination policy in each alert rule’s configuration. Named trees are also available through the Grafana Alerting API, an application programming interface through which other software can manage configuration.
For Terraform, Grafana identifies the resource as grafana_apps_notifications_routingtree_v1beta1. The name comes from resource metadata, information identifying the resource, so separate resources can control separate policies. In Grafana’s example, the resource is called “payments” and metadata.uid is “payments.” Its default receiver is “payments-slack,” with group_by set to ["alertname", "cluster"]. The timing settings are group_wait = "30s", group_interval = "5m" and repeat_interval = "4h": the initial grouping wait, interval between group notifications and repeat-notification interval, respectively.
The example adds two child routes. An equality matcher with label “severity,” type “=” and value “critical” selects “payments-oncall”; another with value “warn” selects “payments-slack.” Each resource can belong to the workspace or repository responsible for that policy. Grafana says the resource supports nested routes, matchers, grouping, notification timing and provenance controls, settings that determine whether a policy remains editable outside Terraform.
A staged migration, not a compulsory rebuild
Multiple notification policies first appeared in Grafana 13.1 behind the alertingMultiplePolicies feature toggle, a switch enabling the capability, before general availability in Grafana 13.2. There is no requirement to divide an existing tree immediately or reassign every rule.