View active notifications
The Alerts page is also the tool for answering routing and suppression questions, because it shows what Alertmanager decided rather than what you configured.
Confirm where an alert was routed
The Receiver column shows the receiver each alert group was sent to.
Use it after any change to the routing tree. Reading a tree and predicting which route matches is error-prone—sibling ordering and inherited settings both catch people out—while this column reports what actually happened. Refer to Configure routes.
You can also filter by receiver, which answers the opposite question: what is this receiver currently being sent?
Find out why a notification wasn’t sent
Alerts in the Suppressed state are firing but not notifying. Open the alert to see which mechanism applied:
The drawer names the specific silence, inhibition, or interval, so you can go and change the right one rather than guessing.
A routing checklist
When an alert fired but nobody heard about it, work through it in this order:
- Is the alert on the Alerts page at all? If not, the ruler isn’t reaching this Alertmanager, or you’re looking at the wrong one in the picker.
- Is it suppressed? The drawer names the cause.
- Which receiver did it go to? If it’s not the one you expected, the routing tree matched a different branch.
- Is the receiver configured correctly? Routing can be right while the integration itself fails: a stale Slack webhook, a rotated PagerDuty key.
The first three are answered on this page. The fourth is the one it can’t tell you about, since Alertmanager considers its job done once it has attempted delivery.
Alerts that resolve
An alert disappears from the page once it stops firing and its grouping timers lapse. There’s no history here. This page is a live view of what Alertmanager holds right now.
For history, use the notification system on the receiving end, or query the alert metrics in your monitoring backend.


