Alerts 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
Looking for Kibana Classic Alerting? Refer to the Kibana Classic Alerting overview.
Kibana Universal Alerting tracks each problem as an alert: the grouping of rule events that share episode.id, from first detection through recovery.
Every alert moves through these states:
inactive → pending → active → recovering → inactive
| State | What it means |
|---|---|
| Inactive | Problem fully resolved, or no problem detected yet. After recovery, an action policy can invoke a workflow to send a recovery notification. |
| Pending | Errors detected, but the system is waiting to confirm it's a real problem before the alert becomes active. This keeps a brief spike from opening and immediately closing an alert. |
| Active | Problem confirmed and ongoing. An action policy can evaluate the alert and invoke a workflow. |
| Recovering | Errors have stopped, but the system is waiting to confirm it's truly resolved. This keeps a single good check from closing an alert while the problem might return. |
Example: A checkout-latency alert moving through all four states
A checkout-latency rule runs every 5 minutes. It has an activation threshold of 2 consecutive breaches and a recovery threshold of 2 consecutive clears. An action policy matches this rule's alerts and invokes a workflow that notifies on-call when the alert becomes active and when it recovers.
- 14:00: Routine check. p95 is within budget. No alert yet. The series is
inactive. - 14:05: p95 jumps to 3.1s. The rule detects the first breach. Kibana writes a rule event, opens the alert in
pending, and starts counting consecutive breaches. - 14:10: p95 is still elevated. The second consecutive breach meets the activation threshold. The alert moves from
pendingtoactive. The action policy invokes the workflow, which pages the engineer. - 14:10–14:45: Every evaluation finds high latency. The alert stays
active. Kibana doesn't open new alerts. One alert tracks one problem, no matter how many times the rule evaluates while the condition holds. - 14:50: p95 drops back under 2s. The first clean check moves the alert from
activetorecovering. The system starts counting consecutive clears. - 14:55: A second consecutive clear meets the recovery threshold. The alert moves from
recoveringtoinactive. The engineer receives a recovery notification.
A series is the ongoing relationship between a rule and one specific thing it monitors. It exists for as long as that rule keeps monitoring that thing, and can contain many alerts over its lifetime, one for each time that thing had a problem.
Snooze operates at the series level, not the alert level. If you snooze checkout-service, you're silencing all notifications from that series for the next X hours, regardless of how many new alerts start during that time.
- View and manage alerts: Open the alerts table, triage active alerts, and acknowledge, snooze, or resolve them.
- Rule events: What Kibana writes to
.rule-eventsand how those events belong to an alert. - Query alert history in Discover: Use ES|QL to query
.rule-eventsand.alert-actionsfor exploratory analysis and dashboards.