Skip to main content
Receivers take grouped alerts from Alertmanager and produce notifications. Each receiver contains one or more notifiers — the integrations that actually deliver messages to third-party systems (Slack, email, PagerDuty, etc.). Notifiers provide the platform-specific configuration required to send those notifications. What you’ll find in this guide:
  • A concise explanation of receivers vs notifiers
  • Examples of route/receiver YAML for Slack and email
  • How to reuse common settings with global
  • How to customize messages using Go templates
  • How grouping (group_by) affects notifications
  • Links to relevant docs and UI tips
A dark-themed slide titled "Receivers" explaining that receivers take grouped alerts and use notifiers to produce notifications. Below the text are five colorful service icons, including recognizable Slack and Gmail logos.

Receiver vs Notifier (quick definitions)

  • Receiver: A logical target for grouped alerts. A receiver contains one or more notifier configurations.
  • Notifier: The specific integration (Slack, email, PagerDuty, webhook, etc.) that sends the notification and defines platform-specific fields.
Common notifiers and their purposes:

Example: Basic route and receiver configuration

  • The route block selects which receiver handles alerts.
  • The receivers section lists receiver definitions and their notifier-specific config fields.
Notes on the example:
  • infra-pager is the receiver name referenced by the route.
  • slack_configs and email_configs contain notifier-specific fields defined by Alertmanager for Slack and email integrations.
  • For the full list of fields per notifier, consult the Alertmanager docs (see References).
You can inspect Alertmanager’s CLI help or run it with a specific config file:
Avoid putting secrets directly in your YAML. Store credentials in a secret manager and reference them securely where possible (for example, by templating during deployment or using your orchestration system’s secret injection).

Global configuration (DRY patterns)

When several receivers share the same values (for example, an API key or mail smarthost), put those shared settings under global. Receivers can then reference those global values rather than repeating them.
A common pattern: move all shared email settings into global and keep only per-team to addresses in each receiver to reduce duplication and simplify updates.

Notification templates (Go templates)

Notifier messages are customizable with Go templates, which let you compose titles and message bodies using alert metadata. Template variables available in Alertmanager include:
  • GroupLabels — labels used to group the notification (e.g., severity, region)
  • CommonLabels — labels common across all alerts in the group
  • CommonAnnotations — annotations common across the group
  • ExternalURL — the Alertmanager UI URL (useful for adding a link back to Alertmanager)
  • Status — firing if at least one alert in the notification is firing; resolved if all are resolved
  • Receiver — the receiver name handling the notification
  • Alerts — list of individual alerts in the notification; each alert exposes Labels, Annotations, Status, StartsAt, and EndsAt
A slide titled "Notification Templates" showing colored field names (GroupLabels, CommonLabels, CommonAnnotations, ExternalURL, Status, Receiver, Alerts) with short explanations. It explains how notifier messages can be configured using the Go templating system.

Slack templating example

Below is an example receiver which sends Slack notifications. The title uses GroupLabels and the text counts and iterates over alerts.
Template notes:
  • Use {{.GroupLabels.severity}} and {{.GroupLabels.region}} to access group label values.
  • {{.Alerts | len}} returns the number of alerts included in the notification.
  • {{range .Alerts}} ... {{end}} iterates through alerts; inside the loop . refers to the current alert object.
  • {{.Annotations.description}} retrieves the description annotation for each alert (if present).
  • Use YAML block scalars (like >) or multi-line strings when templates are too long for a single line.

How grouping affects notifications

The number of notifications you receive depends on your route’s group_by. Alerts with identical values for the keys listed in group_by are bundled into a single notification. Example:
If alerts have these label combinations:
  • region="west", severity="warning" — 2 alerts (grouped together)
  • region="east", severity="critical" — 1 alert
  • region="west", severity="critical" — 1 alert
Alertmanager will send separate notifications for each distinct severity + region combination. The Alertmanager UI (for example, http://localhost:9093) presents grouped notifications according to your group_by settings. You can expand a group to view individual alerts, their labels, and annotations. Example UI view:
Clicking the “Source” button for an alert opens Prometheus’s expression browser pre-filled with the expression that generated the alert. This lets you quickly investigate the underlying metric. Example alert labels and expression that might be pre-filled in Prometheus:

Filtering in the UI

You can filter alerts in Alertmanager by any label key-value pair (for example, env="dev") to focus on a specific subset of alerts.

Summary

  • Receivers define where notifications are sent and contain notifier-specific configurations.
  • Use global to centralize and reuse shared settings (reduce duplication).
  • Customize notifications using Go templates with GroupLabels, Alerts, CommonLabels, etc.
  • group_by determines how alerts are aggregated into a single notification.
  • Alertmanager UI links alerts back to Prometheus for quick investigation.

Watch Video