Simplified Alert Routing and Severity-Based Notifications

Two Ways to Route Alerts

You now have two options for specifying which notification channels receive which alert:

• Bind Notification Channels from Check Rules or Synthetic Checks: Assign notification channels directly within each check rule or synthetic check. This keeps your alert configuration all in one place and gives you explicit control at the individual check level.
• Map Notification Channels to Label-Based Conditions: Define conditions on notification channels to receive alerts that match specific labels. For example, route all alerts labeled team=SRECopy to a dedicated Slack channel, or direct priority=p1Copy alerts to PagerDuty, without modifying individual checks.

Severity-Based Routing

You can now also route alert notifications based on the severity of failed checks using the trigger notifications always or only on Critical options found in the check rule and synthetic check pages, or by using the dash0.failed_check.max_statusCopy attribute.

Use dash0.failed_check.max_status=criticalCopy as a condition on notification channels to ensure only critical alerts trigger pages, while team channels receive all severity levels for visibility.

The dash0.failed_check.max_statusCopy attribute reflects the highest severity a failed check has reached during its lifecycle. Once a check escalates to critical, all subsequent notifications route to channels matching that severity, even if the check temporarily returns to a degraded state. This guarantees that teams who were paged about a failed check will also be notified when it’s resolved.

For more details, see our documentation on Notifications and Routing.