How Kibana stores rule events

Kibana Universal Alerting writes rule events to .rule-events. For what a rule event is and how events belong to an alert, 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:

type What the event represents
signal Queryable in Discover for later analysis. No episode.* fields.
alert One evaluation in an alert. Events that share episode.id belong to the same alert.
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. 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, 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 (for example, acknowledge, snooze, and resolve). Only alerts produce documents here.