﻿---
title: Understand rule events in the experimental alerting system
description: Rule events are the append-only documents Kibana writes to .rule-events for every matching row. Use them to replay alert episodes, investigate type signal events, and build dashboards in the experimental alerting system.
url: https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/rules/rule-event-field-reference
products:
  - Kibana
applies_to:
  - Elastic Cloud Serverless: Experimental
  - Elastic Stack: Experimental since 9.5
---

# Understand rule events in the experimental alerting system
This page explains what Kibana writes to `.rule-events`, how `type` relates to [alert episodes](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts), and how to query that history. For the stored schema, refer to [How Kibana stores rule events](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts/rule-event-data-model). For the complete field list, refer to [Field reference](/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts/field-reference#rule-events-field-schema).
<important>
  The `.rule-events` and `.alert-actions` data streams are [system indices](/elastic/docs-builder/docs/4118/reference/glossary#glossary-system-index). Kibana manages their versioning, retention, and lifecycle through [index lifecycle management (ILM)](https://www.elastic.co/elastic/docs-builder/docs/4118/manage-data/lifecycle/index-lifecycle-management). Older backing indices are deleted automatically when the retention window expires. Do not change mappings or index settings for these streams yourself.
</important>


## How Kibana writes a rule event

A rule event is the record of one result from one rule run. When a rule finds a match, Kibana writes one event per matching row, per run, to `.rule-events`, and never overwrites those events. 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`.
The rule's configuration determines whether that event is grouped into an [alert episode](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts). `type` matches the `kind` you set when you created the rule. Events that aren't part of an alert episode have `type: signal`. For how `kind` is set, refer to [Rule mode](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/rules/configure-rule-mode).
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.

## How `type` relates to alert episodes


| `type`   | What Kibana writes                       | What you work with                                                                                                                                                                                    |
|----------|------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `signal` | A rule event with no `episode.*` fields. | Queryable in Discover for later analysis.                                                                                                                                                             |
| `alert`  | A rule event with `episode.*` fields.    | An [alert episode](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts): events that share `episode.id` appear on the **Alerts** page. |


### Events with `type: signal`

Kibana writes a rule event with `type: signal`. These events stay in `.rule-events`. They don't appear on **Alerts** and aren't evaluated by action policies or lifecycle triggers. They are queryable in Discover.
For query examples, refer to [Query rule events](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts/query-signals).

### Events with `type: alert`

Events with `type: alert` carry `episode.id`, `episode.status`, and `episode.status_count`. Events that share `episode.id` belong to the same [alert episode](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts).
The first event opens the alert 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 alert episode, query every event with that `episode.id`.
Go to **Alerting V2 Preview** in the navigation menu or [global search](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/find-and-organize/find-apps-and-objects), then go to **Alerts** to view the current state of each alert episode.

## Query `.rule-events` to replay an alert 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 alert episode, query `.rule-events` filtered by `episode.id`:
```esql
FROM .rule-events
| WHERE episode.id == "<episode-id>"
| SORT @timestamp ASC
```

For query examples for events with `type: signal`, refer to [Query rule events](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts/query-signals). For lifecycle replay and incident tracing, refer to [Query alert history in Discover](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts/query-alerts-and-signals-in-discover).

## Related pages

- [Rule mode](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/rules/configure-rule-mode): How Rule mode determines whether Kibana groups each rule event into an alert episode or keeps it available for later analysis.
- [Query rule events](https://www.elastic.co/elastic/docs-builder/docs/4118/explore-analyze/alerting/experimental-alerting-system/alerts/query-signals): Query events with `type: signal` in Discover and use them as input to a rule that opens an alert episode.