How routing is selected#
An integration supplies the default service. Enabled routing rules are evaluated in position order, with stable tie-breaking. The first matching rule selects a service; if no rule matches, the integration default remains. Rules may be scoped to an integration or apply more broadly within the organization.
Rule conditions#
Conditions are exact string matches, not arbitrary expressions. All supplied conditions must match. Supported condition fields include source, alert_name, environment, resource, raw source severity, labels.KEY, and annotations.KEY. The severity condition uses the source's severity value; normalized P1–P5 mapping is a separate step.
{
"environment": "production",
"labels.team": "platform"
}Put specific rules before broad fallback rules. Use the integration test and incident routing context to verify the matched rule and destination.
Stable identity across recovery#
Routing binds source alert identity to the selected service. Editing a rule does not automatically move an already-bound condition and strand its recovery. Test a new alert identity when validating a changed rule, and plan migrations of existing integrations deliberately.
Two kinds of deduplication#
| Mechanism | What stays stable | What it prevents |
|---|---|---|
| Transport idempotency | Integration plus idempotency key | A sender retry creating a second accepted raw delivery. |
| Alert fingerprint | Configured condition identity fields | Repeated observations creating unrelated alert identities. |
| Incident lifecycle key | Alert identity and lifecycle start | Reopening the same lifecycle as duplicate incidents after repeated processing. |
Severity mapping#
Source normalization establishes a severity. Service mappings can override it, and integration mappings take precedence over service mappings for matching source values. The organization default applies when source severity is absent. Validate both routing conditions and final P1–P5 severity with realistic payloads.
Common mistakes#
- Putting a changing summary, random request ID, or ingestion timestamp in the fingerprint.
- Using different resource/environment identity on firing and recovery.
- Expecting exact-match conditions to behave like regexes.
- Testing a changed rule only with an existing pinned alert identity.
- Treating a duplicate-accepted response as evidence that the notification reached a human.