Alerts only help when they reach the right place.
In growing teams, notification paths often drift. Someone changes a Slack channel, rotates a webhook, or disables a route temporarily and forgets to re-enable it.
gives you a clear inventory of current alert destinations for a monitor.
Why this endpoint matters
It helps you audit:
- active vs disabled routes
- severity thresholds per channel
- destination targets by monitor
This is especially useful before major send events or after incident-response gaps.
Common signs your routing drifted
If any of these feel familiar, treat routing inventory as a reliability task, not an admin task:
- incidents were detected but not acknowledged quickly
- messages say "alert sent" but nobody saw them
- on-call changes happened and routing never got updated
- teams migrated chat tools (or channels) and old URLs stayed configured
The earlier you detect drift, the less likely you are to learn about it during a deliverability incident.
Endpoint
cURL example
What to look for in the response
When you get the list back, focus on a few high-leverage checks:
- any sink with
that was meant to be temporary - a
route that points to a personal channel instead of on-call tooling - a webhook target that looks like an old environment or deprecated service
- multiple sinks with overlapping thresholds that create duplicate notifications
If you're using webhooks, also review the receiver side:
- does it return fast (204/200) without timing out?
- does it dedupe repeated events?
- does it have signing or allow-listing controls?
Best operational habit
Review alert sink configuration regularly, not just when something breaks.
A monthly route audit catches silent failures before they become expensive incident delays.
A practical audit checklist
Use this checklist when you're about to ship DNS changes or run a high-stakes send:
- Do we have at least one
path that pages on-call? - Are
alerts visible to the team that owns deliverability? - Are there any sinks targeting archived channels or old webhook URLs?
- Are duplicates intentional (for redundancy) or accidental (spam)?
- Can we trigger a test path and observe delivery end-to-end?
If the answer to any of these is "maybe", the inventory endpoint is the starting point for fixing it.
Make routing visible
Monitoring quality depends on detection and delivery. This endpoint covers the delivery side by making routing visible.