Workflow: Routing & Notification Audit
Step-by-step guide for understanding and verifying Alertmanager's routing configuration — who gets paged for which alerts, what receivers are configured, and whether any alerts are falling through to the default route.
When to Use
Use this workflow when:
- Verifying that new routing rules are working correctly
- Investigating why an alert didn't reach the expected receiver
- Auditing the full routing tree for compliance
- Understanding receiver configurations and integration types
Journey
Step-by-Step
| Step | Action | Tool / Resource | Key Parameters |
|---|---|---|---|
| 1 | Inspect routing tree | Resource: am://system/config | Nested route structure with matchers and receivers |
| 2 | List receivers | Resource: am://system/receivers | Receiver names with types (Slack, PagerDuty, email, webhook) |
| 3 | Simulate routing | am_explain_routing(labels={"alertname": "HighCPU", "service": "api", "severity": "critical"}) | Matched receivers + human-readable explanation |
| 4 | Audit default route | am_audit_default_route(backend_id="default") | Alerts hitting the fallback receiver |
Common Routing Questions
| Question | Tool to Use |
|---|---|
| "Who gets paged for this alert?" | am_explain_routing |
| "What Slack channels are configured?" | am://system/receivers |
| "Are any alerts falling through to the default?" | am_audit_default_route |
| "How is the routing tree structured?" | am://system/config |
Next Steps
- Integration Testing — Verify notification integrations
- Governance — Compliance review and audit
- Alert Triage — On-call triage workflow