How Kibana stores rule events in the experimental alerting system

Kibana writes rule events to .rule-events. This page covers where that data lives, which fields each type uses, and where triage actions go. For what a rule event is, refer to Rule events. For how events with type: alert relate to an alert episode, refer to Alerts.

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

type What the event represents
signal Queryable in Discover for later analysis. No episode.* fields.
alert One evaluation in an alert episode. Events that share episode.id belong to the same alert episode.
Note

Rule events with type: signal stay in .rule-events. They don't appear on Alerts and aren't evaluated by action policies or lifecycle triggers.

Events with type: signal and events with type: alert 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 alert episode. Events with type: signal don't include episode.* fields.

For the full field list, including field types and which fields apply to each type, 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 with type: alert.
  • .alert-actions - Records every triage action taken on an alert episode (for example, acknowledge, snooze, and resolve). Only alert episodes produce documents here.