This project is under active development and is not intended for production use.

Notification Routing Rules

Choose which gateways receive an event, and explain the decision before it sends.

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