Routing starts at the route
IncidentRelay keeps incoming alert routing explicit. A route defines the source type, team, schedule or escalation policy, matchers, grouping behavior and attached notification channels.
Common routing patterns
| Pattern | Example matcher |
|---|---|
| Critical production alerts | {"labels":{"env":"prod","severity":"critical"}} |
| Service ownership | {"labels":{"service":"billing-api"}} |
| Kubernetes namespace | {"labels":{"namespace":{"regex":"^prod-"}}} |
| Monitoring source split | {"source":"alertmanager"} |
After matching
After a route matches, IncidentRelay can resolve the affected service, calculate the current on-call user, apply escalation behavior and deliver the notification through the route's channels.
Use route tokens intentionally
Route intake tokens are the boundary for incoming alerts. If a monitoring system needs to send different alert classes into different channels, configure multiple routes and send each receiver to the intended route token.