Notification systems are living systems. Teams change, channels get archived, webhooks rotate, and old routes become dead ends.
When those stale routes stay configured, alerts can appear "sent" but never get seen.
helps you keep routing clean and trustworthy.
What goes wrong when stale routes accumulate
Stale alert routes create two failure modes that are hard to spot:
- silent failure: the destination is dead, but the sender still accepts the request
- alert fatigue: duplicates and outdated channels create noise, so people stop trusting alerts
Both lead to the same outcome: you still "have monitoring", but you don't have response.
Cleanup is part of operating the system, not just tidying.
Delete vs disable
If your system supports it, disabling a sink can be a safer first move while you validate replacements.
Delete is appropriate when:
- the destination URL is rotated and must not be used again
- the channel is permanently retired
- the route is a mistake (wrong team, wrong environment, wrong threshold)
Endpoint
cURL example
means the route was removed successfully.
Safe cleanup checklist
- Confirm replacement route exists.
- Delete stale sink.
- Trigger a test alert path.
- Verify delivery in target channel.
A concrete example: rotating a Slack webhook
Slack incoming webhooks get rotated all the time. A safe workflow looks like this:
- Create a new Slack webhook for the correct channel.
- Add it as a new sink with a low threshold (so you can validate quickly).
- Trigger a manual run and confirm the new channel receives an alert.
- Raise the threshold to match your production policy.
- Delete the old sink so nobody accidentally relies on it.
That avoids "we deleted it and hoped the new one worked" routing, which is how teams discover mistakes during incidents.
Keep routing tidy
Reliable alerting is as much about removing bad routes as adding new ones. This endpoint gives you that cleanup control.