Skip to main content
Alertmanager is the central component that receives alerts from Prometheus instances, deduplicates and groups them, applies suppression and silencing rules, routes them to the correct receivers, and finally dispatches notifications (email, chat, PagerDuty, webhooks, SMS, etc.). It is commonly deployed once per environment or as a clustered, HA set of instances so alerts from multiple Prometheus servers are handled centrally and consistently. How Prometheus sends alerts
  • Prometheus forwards alerts to Alertmanager using its API (for example, the /api/v1/alerts endpoint) or via its alerting configuration.
  • You can configure many Prometheus servers to send alerts to a single Alertmanager instance or to an Alertmanager cluster.
Example: Prometheus minimal alerting config
Alert processing pipeline When Alertmanager receives alerts, they traverse a sequence of processing stages. Each stage transforms or evaluates alerts before they are delivered to receivers. Dispatcher / Receiver (grouping and deduplication)
  • Incoming alerts are grouped and deduplicated based on labels and the Alertmanager configuration.
  • Important grouping settings:
    • group_by: list of labels to group alerts by (alerts with the same values are sent as one notification).
    • group_wait: how long to wait to collect initial alerts for a group before sending the first notification.
    • group_interval: how long to wait before sending a new notification for an ongoing group.
Inhibition
  • Inhibition is rule-based conditional suppression: when an alert X is firing, it can suppress alert Y.
  • Use inhibit_rules to match on labels and define which alerts should be silenced when others are active (useful for suppressing downstream noise when upstream problems exist).
Silences
  • Silences are explicit, time-limited rules created via the Alertmanager UI or API to mute notifications (e.g., planned maintenance).
  • A matching silence prevents notification delivery but does not alter alert firing state in Prometheus.
Routing
  • The routing tree maps alerts (by label match) to one or more receivers (team-specific channels, on-call services, or webhook endpoints).
  • Routes may include matchers, continue flags, and sub-routes to implement complex delivery rules and escalation paths.
Notification engine (formatting and delivery)
  • After routing, the notification engine renders templates and dispatches notifications to configured integrations.
  • The engine handles retries, backoff, rate limiting, and repeat intervals for unresolved alerts (for example, repeat_interval in a receiver).
A labeled architecture diagram of "Alertmanager" showing alerts from Prometheus flowing into dispatching and grouping, then through inhibition, silencing, and routing to a notifications block. The notifications feed into receivers like chat, pager, and email.
Final delivery and high availability
  • Delivery details: Alertmanager observes receiver-specific settings (PagerDuty integration keys, webhook URLs, email configs), repeat intervals for unresolved alerts, and retries with backoff on failure.
  • High availability: Alertmanager supports a gossip-based clustering mode so multiple instances can share state (silences, notifications, routes) and avoid duplicates or missed notifications. In HA setups, ensure network connectivity and consistent configuration across instances.
Best practices (quick checklist)
  • Centralize Alertmanager for an environment to unify routing, silences, and deduplication.
  • Keep group_by and group_wait tuned so related alerts are combined into meaningful notifications.
  • Use inhibitions to reduce noise from downstream systems during upstream outages.
  • Create silences for planned maintenance windows via API or UI, not by muting alerts in Prometheus rules.
  • Test receiver configurations (webhooks, PagerDuty, email) and monitor Alertmanager logs for delivery failures.
Note: Inhibition and silences are different mechanisms. Inhibition is conditional suppression based on other active alerts (rule-based). Silences are explicit, time-bound muting rules you create manually or via API.
Links and references

Watch Video