Rule event data model in the experimental alerting system

Kibana writes rule events to .rule-events. An alert episode is the grouping of those events that share an episode.id. This page covers where that data lives, which fields each type uses, and where triage actions go. For what a rule event is and how it connects to alert episodes, refer to Rule events.

Every time a rule finds a match, Kibana writes a rule event to .rule-events. The event's type is either signal or alert:

Events with type: signal and events that belong to an alert episode share .rule-events and many of the same fields, including data, the payload from your rule's query. Filter with WHERE type == "signal" or WHERE type == "alert".

Only type: alert events carry the episode.* fields that track lifecycle state (episode.id, episode.status, episode.status_count). Query those events by episode.id to replay an episode. Events with type: signal don't include episode fields.

For the full field list, including field types and which fields apply to events with type: signal versus events that belong to an alert episode, refer to Field reference.

Kibana writes rule output to the following append-only data streams, both managed through index lifecycle management (ILM) and queryable with ES|QL in Discover:

• .rule-events - Kibana writes one rule event per matching row, per run, and never overwrites them. When Kibana tracks an alert episode, it can also write recovered and no_data events. This stream holds events with type: signal and events that belong to an alert episode (type: alert).
• .alert-actions - Records every triage action taken on an episode (for example, acknowledge, snooze, and resolve). Only alert episodes produce documents here.

• Rule events: What a rule event is and how it connects to alert episodes.
• Query signals: Query examples for events with type: signal.
• Query experimental alerting system alert history in Discover: Episode lifecycle and triage queries.