Notification Routing Rules
Choose which gateways receive an event, and explain the decision before it sends.
Last updated
2026-08-28 · Audience: Operators + SRE
How a rule matches
Rules are evaluated in ascending priority, with the rule id breaking ties. A populated field must match; an empty list means any value. Disabled rules are skipped. The available match fields are server ids, team names, device classes, locations, event types, and minimum severity.
Each matching rule adds its gateways once. STOP ends evaluation after that rule; CONTINUE keeps evaluating lower-priority rules. If no rule matches, the server policy gateway remains the fallback.
Example: critical escalation
Rule 10 Production critical STOP
locations: ["us-east", "eu-west"]
minimumSeverity: CRITICAL
profileIds: ["pagerduty-critical", "slack-ops"]
Rule 20 Warnings to operations CONTINUE
teamNames: ["platform"]
minimumSeverity: WARNING
profileIds: ["slack-ops"]
Rule 30 Recovery archive CONTINUE
eventTypes: ["RECOVERY"]
profileIds: ["email-audit"]A critical production event matches Rule 10 and stops. A platform warning skips Rule 10, matches Rule 20, and continues to the archive rule if it is also a recovery. Duplicate gateways are removed from the final fan-out.
Create and explain a rule
POST /api/v1/notifications/routing
{
"name": "Critical production",
"priority": 10,
"strategy": "STOP",
"locations": ["us-east"],
"minimumSeverity": "CRITICAL",
"profileIds": ["gateway-critical"]
}
POST /api/v1/notifications/routing/explain
{
"eventType": "THRESHOLD_BREACH",
"severity": "CRITICAL",
"location": "us-east",
"serverId": "server-42"
}The explainer reports every rule, the first criterion that failed, the selected gateways, and the suppression check. Use it before enabling a new rule.
Open Routing Rules