Type to search.

Manage severity escalation notifications in Kibana Universal Alerting

Serverless

Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Serverless interfaces and procedures might differ from classic Elastic Stack deployments.

Stack Planned

The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats.

Availability

  • Planned

    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.

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