How Kibana Universal Alerting works
Each time a Kibana Universal Alerting rule runs, Kibana writes a rule event for each matching row. The rule's mode determines what happens next. The events either belong to an alert that can send notifications, or stay available for later analysis.
In this path, each rule event (type: alert) carries episode.* fields, and events that share episode.id belong to the same alert:
| Step | Actor | Action |
|---|---|---|
| 1 | Rule | Runs on schedule and evaluates ES|QL against your data |
| 2 | Kibana | Query returns results → Writes one rule event per matching row to .rule-events (type: alert) |
| 3 | Kibana | Opens an alert in pending and advances it to active once the activation threshold is met |
| 4 | Dispatcher | Evaluates the alert against each action policy's conditions (eligibility, scope, and frequency) |
| 5 | Dispatcher | If conditions are met, invokes a workflow |
| 6 | Workflow | Sends notification or runs automation |
| 7 | Kibana | Condition clears → Writes a new rule event → The alert moves to recovering → inactive |
| 8 | Dispatcher | Evaluates the recovery event and invokes a workflow if conditions are met |
| 9 | Workflow | Sends the recovery notification |
Steps 4–6 and 8–9 run in a separate background process, the dispatcher, which polls about every 5 seconds. At least one polling cycle passes between a rule run and any notification it causes.
For a minute-by-minute example of an alert moving through these states, refer to Alert lifecycle states.
In this path, each rule event (type: signal) stays in .rule-events. These events don't appear on the Alerts page and aren't evaluated by action policies or lifecycle triggers. They're immediately queryable in Discover, and they can feed a follow-on rule that opens an alert. For query examples, dashboards, and correlation patterns, refer to Query rule events.
A security team wants to track calls to a rarely used administrator API endpoint, but individual calls aren't suspicious enough to page anyone. The team creates a rule that records each call as a rule event without opening an alert.
After a few weeks, the accumulated events become useful in two ways. The team can write a follow-on rule that opens an alert and combines admin API calls with other events (such as a spike in error rates) to catch correlated activity that neither source would surface on its own. When an outage happens, the team can query that history as evidence directly in Discover, without reconstructing the original query or worrying that the source data has become stale.
- Set up Kibana Universal Alerting: Check the requirements and turn the system on or off.
- Create your first rule: Load sample data, create a rule, and observe the alert lifecycle.
- Rules: What rules detect, how action policies invoke workflows, and how to select a creation path.
- Notifications and actions: Set up action policies that invoke workflows for the alerts they apply to.