Configuration

Alertmanager’s alertmanager.yml organizes notification behavior into three primary sections:

global — default values applied across the configuration (can be overridden per receiver).
route — routing tree that determines which alerts are sent to which receivers.
receivers — concrete integrations (Slack, email, PagerDuty, etc.) used to deliver notifications.

Below you’ll find focused explanations, clear examples, and practical patterns for common Alertmanager configuration tasks: routing, matching, grouping, and reloading.

Section	Purpose	Example snippet
Global	Defaults used by notifier integrations	`yaml global: smtp_smarthost: 'mail.example.com:25' smtp_from: 'test@example.com'`
Route	Routing tree and routing defaults (receiver, group_by, etc.)	See “Top-level route” example below
Receivers	Notification delivery settings (Slack, email, etc.)	See “Receivers” example below

Global

Global settings set common defaults consumed by receiver configurations. These are useful for sharing SMTP, Slack webhook, or PagerDuty defaults across multiple receivers.

global:
  smtp_smarthost: 'mail.example.com:25'
  smtp_from: 'test@example.com'

These values apply unless a receiver explicitly overrides them.

Top-level route (default / fallback)

The top-level route defines default routing behavior and acts as the fallback for alerts that don’t match any child routes. You typically set default receiver, group_by, and other defaults here.

route:
  receiver: staff
  group_by: ['alertname', 'job']

  routes:
  - match_re:
      job: (node|windows)
    receiver: infra-email
  - match:
      job: kubernetes
    receiver: k8s-slack

Behavior summary:

Default: alerts are grouped by alertname and job and go to staff.
Child routes override the top-level defaults when an alert matches.
Alerts with job matching (node|windows) go to infra-email.
Alerts with job: kubernetes go to k8s-slack.

Receivers

Receivers define how alerts are forwarded to external systems. Each receiver must have a name and one or more integration configurations.

receivers:
- name: 'k8s-slack'
  slack_configs:
  - channel: '#alerts'
    text: 'https://example.com/alerts/{{ .GroupLabels.app }}'

Notes:

Receivers are referenced by receiver fields in routes.
Templates like {{ .GroupLabels.app }} are evaluated by Alertmanager when building messages.

Matching: match vs match_re

Routes select alerts using matchers. Two common matcher types:

Matcher	Behavior	Example
`match`	Exact label equality (label -> value)	`yaml - match: job: kubernetes severity: ticket receiver: k8s-slack`
`match_re`	Regular expression matching on label values	`yaml - match_re: job: (node\|windows) receiver: infra-email`

Combined example:

route:
  routes:
  - match_re:
      job: (node|windows)
    receiver: infra-email
  - match:
      job: kubernetes
      severity: ticket
    receiver: k8s-slack

Important: match requires exact values; match_re supports regex patterns. Use match_re when you need pattern-based selection.

When using regular expressions, be explicit and test your patterns. A broad regex can unintentionally match many alerts and bypass more specific match routes.

Sub-routes (nested routes)

Routes can be nested to express hierarchical routing rules. Parent routes are evaluated first; child routes refine behavior for a subset of alerts.

route:
  routes:
  - match:
      job: kubernetes
    receiver: k8s-email
    routes:
    - match:
        severity: pager
      receiver: k8s-pager

Behavior:

Alerts with job: kubernetes default to k8s-email.
If an alert also has severity: pager, the child route matches and routes to k8s-pager instead.

This parent/child inheritance applies to fields not explicitly overridden — for example, child routes inherit group_by from their parent unless they specify their own.

Example: Multiple teams with sub-routes

A common pattern is to create one parent route per team and nest child routes for severity or environment-specific behavior.

route:
  routes:
    # database team
    - match:
        team: database
      receiver: database-pager
      routes:
        - match:
            severity: page
          receiver: database-pager
        - match:
            severity: email
          receiver: database-email

    # api team
    - match:
        team: api
      receiver: api-pager
      routes:
        - match:
            severity: page
            env: dev
          receiver: api-ticket
        - match:
            severity: page
          receiver: api-pager
        - match:
            severity: ticket
          receiver: api-ticket

Pattern explanation:

Parent route team: database defaults to database-pager. Child routes route specific severities to alternate receivers.
team: api demonstrates environment-specific routing (e.g., env: dev) and severity-based fallbacks.

Reloading configuration

Alertmanager does not automatically detect changes to alertmanager.yml. To apply updates you must reload the process. Common methods:

Restart the Alertmanager process (e.g., systemd restart).
Send a SIGHUP to the process.
POST to the internal /-/reload HTTP endpoint.

To reload Alertmanager without a full restart you can send SIGHUP (for example: sudo killall -HUP alertmanager) or make an HTTP POST to /-/reload.

Example commands:

# Send SIGHUP to Alertmanager
sudo killall -HUP alertmanager

# Or reload via HTTP (replace host/port as appropriate)
curl -X POST http://localhost:9093/-/reload

Sending an alert to multiple routes (continue)

By default, once an alert matches a route and is processed, Alertmanager stops evaluating further top-level routes for that alert. If you want an alert to be delivered to multiple receivers (for example, a generic logs receiver plus a team-specific receiver), use continue: true on a route.

route:
  routes:
  - receiver: alert-logs
    continue: true
  - match:
      job: kubernetes
    receiver: k8s-email

How it works:

Alerts are first handled by the alert-logs route and processing continues because of continue: true.
If the same alert also matches job: kubernetes, it will additionally be sent to k8s-email.

Grouping alerts (group_by)

Alertmanager groups alerts that match a route into a single notification. Use group_by to control which labels determine grouping granularity.

route:
  receiver: fallback-pager
  group_by: [team]
  routes:
  - match:
      team: infra
    group_by: [region, env]
    receiver: infra-email
    routes:
    - match:
        severity: page
      receiver: infra-pager

Grouping behavior:

Top-level group_by: [team] ensures each distinct team value produces its own grouped notification.
The infra child route overrides grouping to [region, env] so infra alerts are split by region and environment.
Child routes inherit unspecified fields from their parent, so you only need to override group_by where you want different grouping behavior.

Grouping prevents sending one huge notification for many unrelated alerts and lets you fine-tune notification granularity per route.

Quick reference: common route properties

Property	Purpose
`receiver`	Name of receiver to send matched alerts to
`group_by`	Labels used to group alerts into single notifications
`match` / `match_re`	Exact or regex label matchers
`continue`	If `true`, continue evaluating sibling routes after a match
`routes`	Child routes for further matching refinements

Introduction

Observability Fundamentals

Prometheus Fundamentals

PromQL

Dashboarding & Visualization

Application Instrumentation

Service Discovery

Push Gateway

Alerting

Monitoring Kubernetes

Conclusion

Scaling & Long Term Storage

Global

Top-level route (default / fallback)

Receivers

Matching: match vs match_re

Sub-routes (nested routes)

Example: Multiple teams with sub-routes

Reloading configuration

Sending an alert to multiple routes (continue)

Grouping alerts (group_by)

Quick reference: common route properties

Links and references

Watch Video

​Global

​Top-level route (default / fallback)

​Receivers

​Matching: match vs match_re

​Sub-routes (nested routes)

​Example: Multiple teams with sub-routes

​Reloading configuration

​Sending an alert to multiple routes (continue)

​Grouping alerts (group_by)

​Quick reference: common route properties

​Links and references

Watch Video

Global

Top-level route (default / fallback)

Receivers

Matching: match vs match_re

Sub-routes (nested routes)

Example: Multiple teams with sub-routes

Reloading configuration

Sending an alert to multiple routes (continue)

Grouping alerts (group_by)

Quick reference: common route properties

Links and references