---
title: Understand rule events
description: Rule events are the append-only documents Kibana writes to .rule-events for every matching row. Use them to replay alerts, investigate type signal events, and build dashboards.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/rules/rule-event-field-reference
products:
- Elastic Documentation
- Kibana
applies_to:
- Elastic Cloud Serverless: Generally available
- Elastic Stack: Experimental in 9.5
---
# Understand rule events
Kibana Universal Alerting writes a rule event to `.rule-events` for each match. An event's `type` determines whether it belongs to an [alert](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/alerts), and you can query the full history. For the stored schema, refer to [How Kibana stores rule events](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/alerts/rule-event-data-model). For the complete field list, refer to [Field reference](/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/alerts/field-reference#rule-events-field-schema).
The `.rule-events` and `.alert-actions` data streams are [system indices](/elastic/docs-content/pull/8924/reference/glossary#glossary-system-index). Kibana manages their versioning, retention, and lifecycle through [index lifecycle management (ILM)](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/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.
## 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](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/alerts). `type` matches the `kind` you set when you created the rule. Events that aren't part of an alert have `type: signal`. For how `kind` is set, refer to [Rule mode](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/rules/configure-rule-mode).
Most events come from a matching row (`status: breached`). When Kibana tracks an alert, 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 alerts
| `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](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/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://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/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](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/alerts).
The first event opens the alert. 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, query every event with that `episode.id`.
To view the current state of each alert, go to **Alerting** → **Alerts** in the Observability navigation menu, or find **Alerts** using the [global search field](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/find-and-organize/find-apps-and-objects).
## Query `.rule-events` to replay an alert
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, query `.rule-events` filtered by `episode.id`:
```esql
FROM .rule-events
| WHERE episode.id == ""
| SORT @timestamp ASC
```
For query examples for events with `type: signal`, refer to [Query rule events](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/alerts/query-signals). For lifecycle replay and incident tracing, refer to [Query alert history in Discover](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/alerts/query-alerts-and-signals-in-discover).
## Related pages
- [Rule mode](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/rules/configure-rule-mode): How Rule mode determines whether Kibana groups each rule event into an alert or keeps it available for later analysis.
- [Query rule events](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8924/explore-analyze/alerting/esql/alerts/query-signals): Query events with `type: signal` in Discover and use them as input to a rule that opens an alert.