Summary
Notification Policies already support flexible matching through the existing matcher system, including priority and other alert/service attributes.
However, common notification-routing conditions currently require users to configure generic matchers manually.
It would be useful to expose the most commonly used conditions as simple UI filters while continuing to use the existing matcher engine internally.
Proposed filters
Initially, the Notification Policy rule editor could provide convenient selectors for:
- Priority
- Severity
- Alert source
- Service
- Service environment
- Service criticality
- Service tier
For example:
Priority: P1, P2
Severity: Critical, Warning
Source: Sentry
Environment: Production
Criticality: Critical
Tier: Tier 1
These controls should generate the existing matcher configuration rather than introduce a separate filtering mechanism.
Advanced matchers
The current matcher editor should remain available for more advanced conditions such as:
- Labels
- Annotations
- Route attributes
- Custom matcher combinations
This could be presented as an Advanced matchers section alongside the common filters.
Why
This would make common Notification Policy configurations much easier to create and discover, while keeping all notification routing logic within the existing Notification Policy matcher system.
This also addresses the priority-based notification routing use case discussed in #64 without adding duplicate filtering logic directly to Notification Channels.
Summary
Notification Policies already support flexible matching through the existing matcher system, including priority and other alert/service attributes.
However, common notification-routing conditions currently require users to configure generic matchers manually.
It would be useful to expose the most commonly used conditions as simple UI filters while continuing to use the existing matcher engine internally.
Proposed filters
Initially, the Notification Policy rule editor could provide convenient selectors for:
For example:
These controls should generate the existing matcher configuration rather than introduce a separate filtering mechanism.
Advanced matchers
The current matcher editor should remain available for more advanced conditions such as:
This could be presented as an Advanced matchers section alongside the common filters.
Why
This would make common Notification Policy configurations much easier to create and discover, while keeping all notification routing logic within the existing Notification Policy matcher system.
This also addresses the priority-based notification routing use case discussed in #64 without adding duplicate filtering logic directly to Notification Channels.