Rule events in the experimental alerting system
When a rule finds a match, Kibana writes a rule event to .rule-events. Each matching row in a run becomes its own event, and Kibana never overwrites those events. The rule's configuration determines whether that event is grouped into an alert episode. Events that aren't part of an episode have type: signal.
Use this page to query .rule-events with confidence: replay an episode's history, investigate events with type: signal, or build dashboards from rule output. For the stored schema, refer to Rule event data model. For the complete field list, refer to Field reference.
The .rule-events and .alert-actions data streams are system indices. Kibana manages their versioning, retention, and lifecycle through index lifecycle management (ILM). Older backing indices are deleted automatically when the retention window expires. Do not change mappings or index settings for these streams yourself.
A rule event is the record of one result from one rule run. Kibana writes one event per matching row, per run, to .rule-events. It never updates those events in place. Each event is a snapshot of that moment: the rule that produced it, the payload from your query (data), and a type of signal or alert.
Most events come from a matching row (status: breached). When Kibana tracks an alert episode, it can also write events when the condition clears (status: recovered) or when the query finds no data (status: no_data). Kibana writes those events the same way: one new document, never an overwrite.
Each event has a type of signal or alert, matching the kind you set when you created the rule. For how kind is set, refer to Rule mode.
type |
What Kibana writes | What you work with |
|---|---|---|
signal |
A rule event with no episode.* fields. |
Queryable in Discover. |
alert |
A rule event with episode.* fields. |
An alert episode: the grouping of events that share an episode.id, visible on the Alerts page. |
Kibana writes a rule event with type: signal. Action policies evaluate alert episodes only, so these events never reach the Alerts page, a policy, or a workflow. They accumulate in .rule-events and are queryable in Discover.
For query examples, refer to Query signals.
Events with type: alert carry episode.id, episode.status, and episode.status_count. An alert episode is the grouping of those events that share an episode.id.
The first event opens the episode. Later events from later runs advance it through lifecycle states until the condition clears. Because events are never overwritten, episode.status on a given event is the lifecycle stage at that evaluation, not a live field that Kibana updates later. To replay an episode, query every event with that episode.id.
Go to Alerting V2 Preview in the navigation menu or global search, then go to Alerts to view the current state of each episode.
The .rule-events data stream is append-only. Kibana writes a new document on every matching row of every run. Existing documents are never updated. To view the full history of an episode, query .rule-events filtered by episode.id:
FROM .rule-events
| WHERE episode.id == "<episode-id>"
| SORT @timestamp ASC
For query examples for events with type: signal, refer to Query signals. For lifecycle replay and incident tracing, refer to Query alert history in Discover.
- ES|QL query: How the base query and alert condition shape what's written to
.rule-events. - Rules: What rules do and how they fit into the broader experimental alerting system.
- Rule mode: How Rule mode determines whether Kibana groups each rule event into an alert episode or keeps it available for later analysis.
- Query signals: Query events with
type: signalin Discover and use them as input to a rule that opens an episode. - View and manage alerts: Where lifecycle-tracked episodes appear in the UI, with triage actions and episode details.