Rule events in experimental alerting system
This page explains the two types of documents the experimental alerting system writes to .rule-events and how the data stream behaves, so you can write ES|QL queries against .rule-events with confidence, for example, to replay an episode's history, investigate a signal, or build dashboards from rule output.
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.
Each time a rule evaluates, Kibana writes one document per matched series to .rule-events. The type field determines the document kind:
signal- A point-in-time record that the query matched. Useful for querying history or chaining into follow-on rules. Signal documents don't includeepisode.*fields.alert- A lifecycle-tracked episode visible in the alert inbox, episode details, and triage views. Alert documents includeepisode.*fields and represent a breach that stays open until the condition clears.
Both kinds share base fields. Only alert documents add episode fields that carry the lifecycle state for the matched series.
The .rule-events data stream is append-only. A new document is written on every rule evaluation. Existing documents are never updated. Each document is a snapshot of that moment. The episode.status field records the lifecycle stage the episode was in at that evaluation. To view the full history of an episode, query .rule-events filtered by episode.id, for example:
FROM .rule-events
| WHERE episode.id == "<episode-id>"
| SORT @timestamp ASC