OpsCanary
observabilitygrafanaPractitioner

Scaling Grafana Alert Routing: Simplifying Complexity with Multiple Notification Policies

5 min read Grafana BlogReviewed for accuracy
Share
PractitionerHands-on experience recommended

As organizations grow, alert routing often starts simple but becomes increasingly complex. You might find yourself juggling multiple teams, services, and routing requirements. This is where multiple notification policies come into play. They provide a structured way to manage alert routing without adding unnecessary complexity.

Multiple notification policies allow you to split your global routing configuration into smaller, named policy trees. Each policy tree has its own root policy and child routes. Within a selected tree, the routing mechanism remains unchanged: alert labels are matched against routes, which control grouping, notification timings, and contact point selection. The key enhancement is that an alert rule can now specify which policy tree should handle its alerts, giving you more granular control over your alerting strategy.

In production, leveraging multiple notification policies can significantly streamline your alert management. This feature was introduced in Grafana 13.1 and became generally available in 13.2. It’s essential to keep in mind that while this feature simplifies routing, you still need to be vigilant about your alert configurations. Misconfigurations can lead to missed alerts or notifications going to the wrong teams, so thorough testing is crucial before rolling out changes.

Key takeaways

  • Utilize multiple notification policies to create clearer boundaries for alert management.
  • Split global routing configurations into smaller, named policy trees for better organization.
  • Ensure alert rules specify which policy tree handles alerts for improved routing control.

Why it matters

In real production environments, effective alert routing can prevent critical incidents from being overlooked. By using multiple notification policies, you can ensure that the right teams are notified promptly, reducing response times and improving overall system reliability.

Code examples

terraform
1resource "grafana_apps_notifications_routingtree_v1beta1" "payments" {
2  metadata {
3    uid = "payments"
4  }
5
6  spec {
7    defaults {
8      receiver        = "payments-slack"
9      group_by        = ["alertname", "cluster"]
10      group_wait      = "30s"
11      group_interval  = "5m"
12      repeat_interval = "4h"
13    }
14
15    routes {
16      receiver = "payments-oncall"
17
18      matchers = [
19        {
20          label = "severity"
21          type  = "="
22          value = "critical"
23        }
24      ]
25    }
26
27    routes {
28      receiver = "payments-slack"
29
30      matchers = [
31        {
32          label = "severity"
33          type  = "="
34          value = "warn"
35        }
36      ]
37    }
38  }
39}

When NOT to use this

The official docs don't call out specific anti-patterns here. Use your judgment based on your scale and requirements.

Want the complete reference?

Read official docs

Test what you just learned

Quiz questions written from this article

Take the quiz →
DigitalOcean Serverless InferenceSponsor

OpenAI & Anthropic-compatible inference API — no GPU provisioning needed. 55+ models, pay-per-token with no minimums. VPC + zero data retention by default.

Try Serverless Inference →

Get the daily digest

One email. 5 articles. Every morning.

No spam. Unsubscribe anytime.