Stage 6 · Operate

Alerting with Alertmanager

Routing Trees

Designing Alertmanager routes with matchers, continue behavior, receiver inheritance, and team ownership.

7 min readObservability & Monitoring StackOperate

Route Matching

Alertmanager routes determine which receiver handles each alert. Routes form a tree. Each alert walks down the tree until it matches a route. The first matching route wins unless continue is set.

Basic route tree


route:
  receiver: "default"
  group_by: ["alertname", "job"]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h

  routes:
    - match:
        severity: critical
      receiver: "pagerduty-critical"

    - match:
        severity: warning
      receiver: "slack-warnings"

    - match_re:
        team: "database|storage"
      receiver: "team-infra"

Matchers

Matchers define which labels an alert must have to match a route. Alertmanager supports exact match, regex match, and negative match. Modern Alertmanager uses the <label>=<value> syntax.

Matcher syntax


# Exact match
match:
  severity: critical
  team: platform

# Regex match
match_re:
  service: "api|web|gateway"

# Negative match (does NOT match)
match:
  severity: !info

Use match_re for flexibility

match_re lets you match multiple values with a single route. Instead of creating separate routes for each team, use match_re with a pipe-separated regex to match multiple teams in one route.

Continue Behavior

By default, only the first matching route handles an alert. Setting continue: true allows an alert to match multiple routes. This is useful when an alert should go to multiple receivers, such as both Slack and PagerDuty for critical alerts.

Continue for multi-receiver routing


routes:
  - match:
      severity: critical
    receiver: "pagerduty-critical"
    continue: true    # Also check child routes

  - match:
      severity: critical
    receiver: "slack-critical"
    continue: true    # Also check next sibling

  - match:
      severity: critical
    receiver: "email-oncall"

Nested Routes

Routes can nest within routes. A child route inherits the parent's receiver and grouping settings. Child routes add additional matching on top of the parent's matchers. This creates a hierarchical routing tree.

Nested route structure


route:
  receiver: "default-slack"
  group_by: ["alertname"]

  routes:
    - match:
        team: platform
      receiver: "slack-platform"
      routes:
        - match:
            severity: critical
          receiver: "pagerduty-platform"

        - match:
            severity: warning
          receiver: "slack-platform-warnings"

Receiver Inheritance

When a child route does not specify a receiver, it inherits the parent's receiver. This means alerts that do not match any child route go to the parent's default receiver. This creates a fallback mechanism.

Test your routing tree

Use amtool to verify routing behavior before deploying. Run 'amtool config routes test' to confirm alerts reach the correct receivers. A misconfigured route can send critical alerts to the wrong channel.

Team Ownership

Route trees should reflect team ownership. Each team gets a branch with their receiver and grouping settings. This separates alert noise between teams and ensures the right people get paged.

Team-based routing


route:
  receiver: "default"
  routes:
    - match:
        team: platform
      receiver: "slack-platform"
    - match:
        team: database
      receiver: "slack-database"
    - match:
        team: payments
      receiver: "pagerduty-payments"
      continue: true
    - match:
        team: payments
      receiver: "slack-payments"

Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.