Skip to main content
Receivers take grouped alerts from Alertmanager and produce notifications. Each receiver contains one or more notifiers that integrate with external platforms such as Slack, email, or VictorOps. Receivers map Alertmanager routes to the appropriate notification backends and format the alert payloads sent to those systems.
The image explains that receivers are responsible for taking grouped alerts and producing notifications, and it shows icons of notification services like Slack and Gmail.

Configuring receivers in Alertmanager

A minimal Alertmanager configuration forwards alerts to a receiver named infra-pager like this:
The receivers list may contain multiple receivers. Each receiver defines one or more notifier blocks (for example slack_configs, email_configs, victorops_configs, etc.). The precise fields required depend on the notifier; consult the notifier documentation when in doubt. Common notifier examples and the typical fields they require:
If multiple receivers use the same secrets (API keys, SMTP credentials, etc.), move shared values into the global section to avoid duplication and simplify maintenance.
For example, moving a VictorOps API key into global:
This way, each receiver can reference global credentials instead of duplicating secrets across entries.
Never commit API keys, passwords, or other secrets in plaintext to public repositories. Use secret management tools or environment injection when deploying Alertmanager configuration.

Templating the notification content

Alertmanager uses Go templates to format notification content. Templates can access the alert group and individual alert metadata, letting you create concise, informative messages targeted to each notifier. Common template fields: Always present templates inside fenced code blocks. Example Slack notifier with a custom title and message body:
How the template works:
  • title uses {{ .GroupLabels.severity }} and {{ .GroupLabels.region }} to surface grouped label values (for example: critical alerts in region west).
  • text uses the len function to show the number of alerts and range .Alerts to iterate through every alert, printing the description annotation for each.
When template strings are long, prefer YAML’s folded scalar > for readability while preserving the final output format.

Grouping alerts

Alert grouping is controlled by the route configuration. Grouping determines which alerts are merged into a single notification. Example: group alerts by severity and region:
Alerts that share the same values for those labels (for example severity=warning and region=us-west) are bundled into a single notification. Different label combinations produce separate notifications (for example, severity=warning, region=us-west and severity=critical, region=us-east become two notifications). Grouping behavior examples:
The image shows an Alertmanager dashboard displaying two filesystem alerts with a "warning" severity for low space on a specified device.

Inspecting alerts in the Alertmanager UI

The Alertmanager UI lets you expand groups to view individual alerts, inspect labels, and follow links to the source Prometheus expressions that triggered them. Click the “Source” button to navigate to the Prometheus expression. Example alerting rule expression:
You can filter alerts in the UI by label key-value pairs (for example: region="east" severity="critical"). A typical alert label set might look like:
Use label filters and the templated ExternalURL links in notifications to quickly jump from an alert to the Prometheus graph or rule that generated it, speeding up triage and remediation. Further reading and references

Watch Video