Overview of Alertmanager architecture and alert processing flow from Prometheus including grouping, silences, inhibition, routing, and notification delivery to integrations
In this lesson we will learn about the architecture of Alertmanager and how it processes alerts from Prometheus.What is Alertmanager?
Alertmanager receives alerts generated by one or more Prometheus servers and turns them into notifications. These notifications can be sent via integrations such as PagerDuty, webhooks, email, SMS, and chat. Multiple Prometheus servers can be configured to forward alerts to a single Alertmanager instance (or a highly available cluster of Alertmanagers) using the Alertmanager API.High-level processing flow
When alerts arrive at Alertmanager they are processed through several stages in sequence. The core stages are: dispatching/grouping, silences, inhibition, routing, and finally notification delivery. The following diagram shows this flow and the typical receivers:
Dispatcher / grouping
The first component that handles incoming alerts is the dispatcher (also called the grouping engine). It receives alerts and groups them according to your grouping configuration (for example by alertname and instance). Grouping controls how alerts are batched into notification messages and also helps with deduplication so that related alerts are sent together rather than as many individual notifications.Silences
After grouping, alerts are evaluated against configured silences. Silences are temporary muting rules you create (often via the Alertmanager UI or API) to suppress notifications for known maintenance windows or expected disruptions. When a silence matches an alert, that alert’s notifications will be suppressed for the duration of the silence.Inhibition
Following grouping and silences, alerts pass through the inhibition logic. Inhibition allows you to suppress one alert when a related alert is firing (and not silenced). For example, you can configure a rule that says: if alert X exists and is active, suppress alert Y. This is useful to avoid noisy or redundant notifications when a single root cause generates multiple dependent alerts.Silences vs. Inhibition note:
Silences explicitly mute alerts for a configured time window. Inhibition conditionally suppresses notifications for target alerts when one or more source alerts are active; typically a source alert must be firing (and not silenced) for inhibition to take effect.Routing
The routing tree determines which alerts are sent to which receivers and via which integration. Routes are matched based on alert labels and can inherit settings from parent routes. Routing controls:
which receiver (or receivers) should get a particular alert,
the grouping behavior and timing (how long to wait before sending grouped alerts),
and any route-specific notification settings.
Notification engine
Once the routing logic has determined the receiver(s), the notification engine is responsible for actually delivering the notifications to the configured integrations (email, PagerDuty, webhooks, chat platforms, etc.). It handles formatting the messages, retrying failed deliveries, and tracking notification statuses.Putting it together
Prometheus sends alerts to Alertmanager via its API.
The dispatcher groups alerts.
Silences temporarily mute alerts for planned events or maintenance.
Inhibition suppresses dependent or redundant alerts when configured source alerts are active.
Routing decides which receiver(s) should be notified.
The notification engine delivers the alerts to external systems.
Configure grouping, inhibition, silences, and routing thoughtfully to minimize noisy alerts and ensure the right teams receive meaningful notifications.
