Manage severity escalation notifications in Kibana Universal Alerting
Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud. Availability This functionality is generally available and ready for production usage. Serverless interfaces and procedures might differ from classic Elastic Stack deployments. The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats. Availability We plan to add this functionality in a future Elastic Stack update. Subject to changes. Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments. This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.
Serverless
Generally available
Stack
Planned
Planned
Not every severity change in Kibana Universal Alerting invokes a workflow. The outcome depends on whether the action policy has already matched the alert and which frequency option you've selected. You can control what happens on first-time matches, duplicate invocations, and de-escalation.
Scope an action policy to the severity level you want a workflow to run for. When an alert escalates into that severity level for the first time, the action policy invokes a workflow because it has no prior invocation record for the alert.
The following example uses an action policy scoped to severity: "critical". An alert starts at low severity, so the action policy doesn't match. When the alert escalates to critical, the action policy now matches and invokes a workflow regardless of the frequency setting, because it has never invoked a workflow for this alert before.
| Field | Value |
|---|---|
| Match conditions | severity: "critical" |
| Notify per | Alert |
| Frequency | On status change |
| Destinations | PagerDuty workflow |
If an action policy already matched an alert, a severity escalation alone doesn't trigger re-notification when the alert's status stays the same. With On status change frequency, a severity change doesn't count as a status change.
In this example, Action Policy A matches all alerts regardless of severity and notified when the alert was low. When the alert escalates to critical, Action Policy A still matches, but the throttle blocks re-notification because the status hasn't changed. To re-notify on escalation, use a time-based throttle or create separate action policies for each severity level as described in Route alerts by severity.
| Field | Value |
|---|---|
| Match conditions | (None, matches all alerts) |
| Notify per | Alert |
| Frequency | On status change |
| Destinations | Slack workflow |
If an alert drops below an action policy's severity threshold, the action policy stops matching and doesn't invoke a workflow. If the alert later escalates back above the threshold, the action policy invokes a workflow again as if it were the first match.
In this example, Action Policy B targets only severity: "critical" alerts. An alert de-escalates from critical to high. Action Policy B no longer matches and stops invoking a workflow. If the alert later escalates back to critical, Action Policy B invokes a workflow again.
| Field | Value |
|---|---|
| Match conditions | severity: "critical" |
| Notify per | Alert |
| Frequency | On status change |
| Destinations | PagerDuty workflow |
- Route alerts by severity: Configure severity-scoped action policies to route alerts to separate workflows.
- Re-notify for persistently active alerts: Set up time-based frequency options to re-notify when an alert stays active.
- Action policy reference: Look up match condition fields and frequency options.