Kibana Universal Alerting will be generally available and on by default in Elastic Cloud Serverless on October 20, 2026, and in Elastic Stack 9.6 for Elastic Cloud Hosted and self-managed deployments. Already have alerts in Kibana? The new system runs alongside your existing Classic Alerting system, so you can adopt what you like at your own pace.

Kibana Classic Alerting continues to handle common scenarios well. Pick a rule type, fill in its parameters, and attach actions as you always have. Classic Alerting is as simple and reliable as ever. Universal Alerting goes further, enabling you to express any ES|QL query as an alerting rule, control flapping with alert and recovery delay, use custom recovery queries, shape alert data to fit your needs, and schedule actions that respond and group alerts across your rules.

When Universal Alerting fits

It's a good fit when one or more of these is true:

1. Your alert scenarios go beyond what Classic Alerting can offer, e.g., custom severities, workflow-powered actions, alert data control, full control over recovery, and more.
2. You want the flexibility of building rules using simplified query builders and later "dropping down" to edit and expand the generated ES|QL.
3. Your alerts come from more than one system, and you want to triage and analyze them in one view.
4. Fine-grained notification control matters, e.g., who is notified and how often, cross-rule grouping and processing, and more.
5. Your team wants all the flexibility offered by Discover, ES|QL, and Workflows. Universal Alerting integrates perfectly with and depends on all of these foundational Elastic features.

If a Classic rule type already covers your scenario, keep using it. We compare the two systems side by side later in this post.

How Universal Alerting works: From ES|QL query rules to alert data

A Universal Alerting rule runs an ES|QL query on a schedule. Each result is written as a rule event to a dedicated data stream, .rule-events. Four core ideas define the system:

• Rules are ES|QL queries, so there are no rule types to pick from. Each row the query returns, identified by its group, becomes a rule event, and the columns it returns are stored with the event. The query defines the shape of the alert.
• Alerts are data. Rule events live in a regular data stream with a documented schema, whether they came from Kibana alerting rules or an external tool. They can be searched in Discover, charted on dashboards, and used as the input for other rules.
• An alert follows one ongoing problem through its lifecycle (pending, active, recovering, inactive) and groups all of its underlying rule events as the alert's history. A rule doesn't trigger a new alert on every run, nor does it update an existing alert document. Rule events can be captured without triggering alerts. These are simply collected as data.
• Action policies live outside rules. They match on alert data, group and throttle them, and send them to workflows. Changing who gets notified doesn't mean editing an action per rule.

Each of these is a separate component, and each one offers flexibility and controls on its own.

The SRE workflow: Author and shape one rule

Say you run production hosts across several availability zones. The goal is to alert when a host stays hot, with the severity level and availability zone the on-call engineer needs. A brief spike shouldn't count. The host examples use metrics from the Elastic Agent System integration (system.* fields), and the pod example later uses the Kubernetes integration (kubernetes.* fields). Swap in your own fields as needed.

Author: One ES|QL rule, written the way you already query

This rule computes average CPU per host, assigns a severity and returns only the hosts worth a look:

/*
  Average CPU per host, with a severity and a minimum-sample guard.
*/
FROM metrics-*
| WHERE system.cpu.total.norm.pct IS NOT NULL
| STATS
    avg_cpu_pct = ROUND(AVG(system.cpu.total.norm.pct) * 100, 0),
    samples = COUNT(*)
  BY host.name, cloud.availability_zone
    /* A column named severity sets the alert's built-in severity field
       (info, low, medium, high or critical). Hosts below every threshold get
       no severity, and the WHERE below drops them. The other returned
       columns, such as avg_cpu_pct and the zone, are stored on the alert and
       available to action policies and dashboards later. */
| EVAL severity = CASE(avg_cpu_pct > 95, "critical", avg_cpu_pct > 90, "high", avg_cpu_pct > 85, "medium")
| WHERE samples >= 10 AND severity IS NOT NULL
    /* A minimum-sample guard skips hosts that just came up and have only
       reported a few data points. */
| KEEP host.name, cloud.availability_zone, avg_cpu_pct, severity, samples

Shape: Decide how the alert behaves over time

The query decides what matches. The rule definition decides what happens as matches come and go. Here's the same rule in YAML, split into a base query, a breach condition, and a recovery condition:

kind: alert

metadata:
  name: host-cpu-saturation
  routing_tags: [infra]                 # links this rule to action policies (lever 5)

schedule:
  every: 1m
  lookback: 5m

query:
  base: |
    FROM metrics-*
    | WHERE system.cpu.total.norm.pct IS NOT NULL
    | STATS
        avg_cpu_pct = ROUND(AVG(system.cpu.total.norm.pct) * 100, 0),
        samples = COUNT(*)
      BY host.name, cloud.availability_zone
    | EVAL severity = CASE(avg_cpu_pct > 95, "critical", avg_cpu_pct > 90, "high", avg_cpu_pct > 85, "medium")
  breach:
    segment: WHERE samples >= 10 AND severity IS NOT NULL

recovery:
  strategy: condition
  segment: WHERE avg_cpu_pct < 70       # recover well below the breach threshold

no_data:
  strategy: keep_last                   # a host that is rebooting keeps its last known status

state_transition:
  pending:
    count: 2                            # alert delay: the alert goes active on the third consecutive breach
  recovering:
    count: 2                            # recovery delay: the alert goes inactive on the third consecutive recovery

grouping:
  fields: [host.name, cloud.availability_zone]   # one alert per host

Recovery, state transitions, grouping and no-data handling are each tunable, and levers 1 to 4 below cover them. Levers 5 and 6 pick up once the alert is active: who gets notified, and how responders triage it.

Six levers for fine-tuning your alerts

Universal Alerting has a control at each stage of the pipeline, listed here from earliest to latest. Use only the ones a scenario calls for.

1. The query: Decide exactly what counts

ES|QL has everything needed to define a condition precisely. WHERE sets the scope, a minimum-sample guard ignores hosts that just came up, CASE assigns severities, and SORT with LIMIT restricts alerts to the worst offenders.

/*
  Alert on only the three hottest pods, not every pod above the line.
*/
FROM metrics-*
| WHERE kubernetes.pod.cpu.usage.node.pct IS NOT NULL
| STATS avg_cpu_pct = ROUND(AVG(kubernetes.pod.cpu.usage.node.pct) * 100, 1) BY kubernetes.pod.name
| SORT avg_cpu_pct DESC
| KEEP kubernetes.pod.name, avg_cpu_pct
| LIMIT 3
    /* LIMIT caps the number of alerts a single run can produce.
       Use it when "the worst few" is the question you care about. */

LIMIT has one side effect to plan for. A pod that drops out of the top three disappears from the results. With no_breach recovery, that counts as recovered, and the alert can activate again if the pod climbs back. If that matters for your rule, pair LIMIT with a recovery delay (lever 3).

2. Grouping: Choose the unit of an alert

STATS ... BY defines what a single alert is. Group by host.name for one alert per host, or by service.name for one per service. Pick the unit someone can act on: a grouping that's too wide hides problems, and one that's too narrow multiplies them. If a grouping field is missing from some documents, those rows fall into a single null group and share one alert, while the other groups keep their own alerts. Handle missing values explicitly in the query if that matters.

Alerting rules return at most 1,000 rows unless you set a LIMIT. If a single run could produce more groups than that, add an explicit LIMIT.

3. Alert delay and recovery delay: Define how an alert starts and ends

Thirty seconds over a threshold isn't always an incident. An instance of recovery isn't always indicative of a real recovery. This kind of flapping is one of the biggest sources of alert noise, and two delay configurations handle it without touching the query.

The alert delay (state_transition.pending) is the number of evaluations an alert spends in the pending state before it goes active. With count: 2, the alert goes active on the third consecutive breach, so a short spike stays pending and never becomes an alert.

The recovery delay (state_transition.recovering) does the same for the recovering state before the alert goes inactive. A signal that bounces around the threshold stays one alert. Each phase accepts a count, a timeframe or both, plus an operator (and or or) that says whether both must be met or just one.

Recovery is a separate setting, and every alert rule must set one (no_breach by default):

• no_breach recovers an alert when its group stops appearing in the breach results.
• condition recovers it when a different recovery condition (as opposed to alert condition) on the same base query is met, as in the rule above.
• query recovers it when a separate ES|QL query returns the alert's group. Recovery is per group, so each alert recovers only when the query returns its group.
• manual never recovers on its own. The alert stays active until someone manually resolves it.

A common pattern is to recover well below the breach threshold; for example, breach at 90% CPU and recover under 67%. That way, an alert doesn't close the moment the metric dips under the line. And because query recovery can run its own ES|QL query, it can check different values than the breach does. The example below requires both CPU and load average to be back to normal before the alert closes:

# A recovery query that looks at more than the breach query does.
recovery:
  strategy: query
  query: |
    FROM metrics-*
    | STATS
        avg_cpu_pct = ROUND(AVG(system.cpu.total.norm.pct) * 100, 0),
        load_avg_5m = AVG(system.load.5)
      BY host.name, cloud.availability_zone
    | WHERE avg_cpu_pct < 67 AND load_avg_5m < 4
    | KEEP host.name, cloud.availability_zone

4. No-data handling: Decide what silence means

When a group with an active alert stops showing up in the breach results, there are two very different explanations. Either the problem cleared up or the data source stopped reporting, and the alert condition alone can't tell them apart. No-data handling lets you decide, per rule, what happens in that moment, so a broken metrics agent doesn't quietly recover a real alert.

Set it with no_data.strategy, or with the no-data setting in the rule builder:

| Option | no_data.strategy | What happens | | --- | --- | --- | | Keep last status | keep_last | Holds the last known state. An active alert stays active, and a recovering alert stays recovering. A status:no_data rule event is written to the data stream.| | Recover | resolve | Closes the alert the first time no data is found, moving it straight to inactive without waiting for the recovery delay. A status:no_data rule event is written to the data stream.| | Do nothing | ignore | Skips the no-data check. With no_breach recovery, a gap in data looks like a recovery. With condition or query recovery, no event is written and the alert stays active. |

The right choice depends on what silence means for the rule. For infrastructure CPU, use Keep last status: if the agent stops sending data, an active CPU breach stays active until data comes back. For a rule that triggers an alert when a job backlog grows too large, Recover makes sense. Once the queue is empty, the query has nothing to return and the alert closes.

5. Action policies: Route, group and throttle

Rules don't carry their own actions. Instead, an action policy selects alerts, bundles them into a payload, controls how often they repeat and dispatches them to a workflow. One action policy can cover alerts from many rules, so changing who gets paged for a hundred rules takes a single edit.

Policy scope selects the alerts an action policy handles, in two parts that can be combined. Routing tags limit the action policy to alerts from rules that carry at least one of those tags. Under Advanced matching, a KQL expression filters on alert fields such as severity, group_hash or data.*. When both are set, an alert has to pass both.

Routing tags connect an action policy to a rule. Add them in the Routing tags field on the Actions step of the rule form, and select the same tags in the action policy form. From then on, the action policy applies to every rule that carries one of those tags, including rules created later. The rule form's Applied policies panel lists every action policy that matches the rule, so the connection is easy to verify. To target a single rule, give it a routing tag that no other rule uses. Attaching or detaching a rule is then a matter of editing its routing tags, and the action policy itself doesn't change.

Routing tags aren't the same as a rule's regular tags. Regular tags group and filter rules in the rule list. They have no effect on notifications, so adding a regular tag to a rule never attaches an action policy to it.

Two more settings shape the notifications. Notify per controls bundling: one notification per alert, one per group of alerts across rules that share a field value such as the availability zone, or a single digest of everything the action policy matches. Frequency limits repeats, for example to at most once every 30 minutes.

Here are two action policies for the CPU rule, written as the settings chosen in the UI. Both are tied to the rule through its infra routing tag:

# Page the on-call engineer only for critical hosts, one page per availability zone.
Name:           infra-oncall-pager
Policy scope:   Routing tags: infra
                Advanced matching (KQL): severity : "critical"
Notify per:     Group, by data.cloud.availability_zone
Frequency:      At most once every 30 minutes
Destination:    pagerduty-infra workflow

# Send the lower severities to the infrastructure channel, batched per zone, at most hourly.
Name:           infra-team-digest
Policy scope:   Routing tags: infra
                Advanced matching (KQL): severity : "high" or severity : "medium"
Notify per:     Group, by data.cloud.availability_zone
Frequency:      At most once every 1 hour
Destination:    slack-infra-team workflow

An alert can match several action policies, and each one applies its own grouping and frequency. If a whole zone runs hot, the pager gets one grouped page rather than one per host, and the team channel gets an hourly summary of the high and medium hosts.

Action policies also work across rules. Give your CPU, memory and disk rules the same routing tag, select that tag in an action policy and set Notify per to Group by data.cloud.availability_zone. A zone where all three rules fire then sends one page instead of three. Switch Notify per to Digest, and the action policy sends a single notification for everything it matches. To alert on the pattern itself, see rules on top of your alerts. Expand commentComment on line R230Resolved Each destination in these examples is a workflow that calls your connector, such as Slack or PagerDuty. To learn how to build and enable one, see the Workflows documentation.

6. Triage controls and maintenance windows: Quiet things on purpose

Once an alert is active, a responder can acknowledge it, snooze the series for a set period or resolve it. Suppressed alerts stay out of notification channels but remain in the data. Nothing is deleted, and everything stays auditable. During a planned rollout, for example, snoozing the series keeps it out of notification channels until the snooze expires. Maintenance windows do the same for scheduled work and apply to Universal Alerting and Classic rules alike.

One place for all your alerts: Classic, Universal, and even external

Few teams have a single source of alerts. Some come from Classic Alerting rules, some from Universal Alerting rules, and some from other monitoring tools. Our new alerts views are built so responders can work from a single queue.

Alerts from other tools, as data

Alerts from external monitoring tools land in the same data stream as the alerts Elastic generates, and are searched, routed and triaged the same way. A workflow writes each one with the alerting.create_alert step, and the source field records where it came from. For the on-call engineer, that's one place to check instead of a tab per tool. External alert ingestion is an experimental feature, so expect it to change and improve as we learn how it's used.

Universal vs. Classic feature comparison

The two systems share a goal but make different tradeoffs. Classic Alerting favors guided setup for known scenarios, while Universal Alerting favors flexibility and control.

| Feature | Classic | Universal | | --- | :---: | :---: | | Prebuilt rule types with guided parameters | ✓ | Partial, more to come | | Rules written as ES|QL queries | ✓ | ✓ | | Basic threshold rules | ✓ | ✓ | | Anomaly detection and APM anomaly rules | ✓ | Coming soon | | Machine learning job health and transform health rules | ✓ | Coming soon | | SLO burn rate rules | ✓ | Coming soon | | Synthetics monitor status rules | ✓ | Coming soon | | Alert fields defined by the rule's query | | ✓ | | Alert event historical data, per run | | ✓ | | Alert delay (consecutive breaches before an alert goes active) | ✓ | ✓ | | Recovery delay (consecutive recoveries before an alert auto-recovers) | | ✓ | | Custom recovery condition or recovery query | | ✓ | | Actions attached to each rule, sent directly to connectors | ✓ | | | Reusable action policies shared across many rules, with grouping and throttling | | ✓ | | Import alerts from external tools (experimental) | | ✓ | | Triage and analysis in the combined Alerts page | ✓ | ✓ | | Maintenance windows | ✓ | ✓ |

Universal and Classic alerts appear together on the combined Alerts page, so responders triage everything in one view. Classic Alerting keeps running exactly as it does today. Maintenance windows, connectors, and workflows are shared across both systems.

New alerting capabilities are actively being built in Universal Alerting. Classic rules remain a good fit for the standard scenarios they were designed for, and you can adopt Universal Alerting at your own pace, one rule at a time.

What Universal Alerting doesn't do (yet)

Universal Alerting doesn't match Classic Alerting feature for feature yet. We'd rather you hear about the gaps now than discover them mid-incident, so here's what to know before moving a rule over.

• Not every Classic rule type has a Universal equivalent yet. Universal rules are ES|QL queries, written by hand or generated by the rule builder. Threshold-style rules, such as custom, metric, log and index threshold rules, map well to the threshold rule builder, and many other conditions can be written directly in ES|QL. Rule types that rely on results computed elsewhere in the stack, such as anomaly detection, don't have a Universal counterpart yet, so those rules stay on Classic for now. The comparison table above lists them, and the rule library on our roadmap will add ready-made starting points for common patterns.
• SLO and synthetics rules need extra work. Their conditions can be written in ES|QL against the SLO and synthetics data, but the multi-window burn rate logic and per-monitor settings of the Classic rules have to be rebuilt by hand. Keep those rules on Classic unless you need the extra control.
• Classic rules are not automatically migrated to the Universal system. They keep running unchanged, and moving one to Universal Alerting means rebuilding its condition as an ES|QL rule.
• Universal Alerting actions depend on workflows. A Classic rule sends its actions straight to connectors. A Universal rule has no actions of its own: action policies hand alerts to workflows, which are the only destination type, and the workflow then calls Slack, PagerDuty or any other connector. Before a Universal rule can notify anyone, at least one workflow must exist and be enabled.
• Workflows require an Enterprise license on Elastic Cloud Hosted and self-managed deployments. Without this license, Universal rules still run and alerts are still written, but action policies cannot deliver to any destination, so no notifications go out. Existing action policies can still be viewed, disabled, snoozed and deleted.
• Universal alerts don't provide flapping state configuration. Alert and recovery delays and custom recovery (lever 3) are the way to keep a noisy alert from firing too often.
• Field names may differ between the two alert types. A query on a Universal alert field such as group_hash won't match any Classic alerts. Our unified alerts table mostly hides this distinction, but use shared filters (status, severity, rule, tags) in your own combined queries, or query each system separately.

Two delivery details apply to every action policy. Notifications are delivered at least once, so in rare cases, such as a restart between dispatch and recording, the same notification can arrive twice. Make workflows idempotent. Notifications are also dispatched on a short polling interval rather than instantly, so don't depend on sub-second paging latency.

Understand your alerting with ES|QL

An alert and its history are documents in a data stream, so the language that defines a rule can also answer questions about your alerting. From an alert, jump into Discover and pivot to that host's metrics and logs without a separate tool. Both examples below query the .rule-events data stream.

/*
  The ten rules that activated the most alerts in the last 7 days.
  rule.id is the rule's saved object ID, not its name.
*/
FROM .rule-events
| STATS alerts = COUNT_DISTINCT(alert.id) BY rule.id
| SORT alerts DESC
| LIMIT 10
    /* Rules at the top are good candidates for tuning. Adjust a threshold,
       raise the alert delay or change the grouping, then re-run this. */

/*
  Alert volume per day for one rule, to confirm a change had the effect you wanted.
  rule.id is the rule's saved object ID, not its name.
*/
FROM .rule-events
| WHERE rule.id == "<your-rule-id>" AND type == "alert"
| STATS alerts = COUNT_DISTINCT(alert.id) BY day = BUCKET(@timestamp, 1 day)
| SORT day ASC

Rules on top of your alerts

Since alerts are data, rules can run over them too. A rule on alert data is an ordinary ES|QL rule that reads .rule-events instead of logs and metrics. That lets it catch a pattern no single alert shows, such as three or more rules firing in the same availability zone. Alerts from Universal rules and from external tools work the same way here, because both land in the same data stream with the same fields. The alerts such a rule produces get the same lifecycle, action policies and triage controls as any other alert.

Signal rules are the building blocks for this. A rule with kind: signal (labeled Events in the UI) records breach and recovery events as data, without triggering alerts or notifying anyone. Use signal rules for conditions that matter mostly in combination, like high CPU, low free disk and elevated I/O wait on the same host. Then write an alert rule that fires when several of those signals line up.

What we're working on next

Try upcoming features per space

New and upcoming Kibana Universal Alerting features will ship behind an experimental feature flag, so teams can try them before they're enabled for everyone. The flag is the Universal Alerting: Experimental Features setting (alerting:v2:experimentalFeatures). It's off by default and set per Kibana space, so you can turn it on in a test or staging space and leave production spaces as they are. Changing it requires a page reload.

The flag gates every upcoming Universal Alerting feature. Everything that ships at GA works without it.

What's coming

While we aren't committing to any specific dates, this is where we're focused after GA:

• Sequence rule builder GA: A guided way to build rules that detect events happening in a particular order, without writing the whole query by hand (already available via "experimental features").
• More rule builders: Provide more guided ways to build rule queries. (SLO, synthetics, anomaly detection, etc.)
• A rule library of ready-made rules to start from and adapt, so a new rule doesn't begin with a blank query.
• Alert deletion, for alerts that are no longer needed.
• External alert import, generally available, with simpler setup and management.
• Bi-directional alert syncing with external systems, so an action taken in one system is reflected in the other.
• Further "no data" features.

If one of these matters more to you than the rest, tell us. It helps us decide what to build first.

Get started

Universal Alerting is generally available on Elastic Cloud Serverless, and on Elastic Cloud Hosted and self-managed deployments starting with Elastic Stack 9.6. On Elastic Cloud Hosted and self-managed deployments, workflow-based action policies require an Enterprise license, which includes 10,000 workflow executions per month (see subscriptions). On Serverless, Elastic manages the alerting system.

Give your team access

Access is controlled with Kibana feature privileges, set per role in Stack Management > Roles. Universal Alerting adds four, listed under Universal Alerting in the role editor, each with its own All or Read level:

| Privilege | Read | All | | --- | --- | --- | | Rules | View rules | Create, edit and delete rules | | Alerts | View alerts | Triage alerts | | Action Policies | View action policies | Create and edit action policies | | Execution history | View execution history | Same as Read |

Most responders need Alerts: All and Rules: Read. Rule authors need Rules: All, plus Action Policies: All if they also manage notifications. Notifications run through workflows, so anyone who builds or edits them also needs All for Analytics > Workflows. See Set up Workflows for the full list of Workflows privileges.

Privileges control what a user can manage, not what data a rule can read. Each rule runs with the API key of the user who last saved it, and that key determines what data the rule can query. Save your rules as a user who can read the indices they query. For how rules, action policies and workflows are authorized, see the authorization documentation.

Create your first rule

Open the Universal rules tab, create your first rule and tell us what you find. If something comes up that we didn't cover here, we want to hear about it.

Don't have a deployment yet? Start an Elastic Cloud free trial.