﻿---
title: Rule events in experimental alerting system
description: How the experimental alerting system in Kibana writes rule events to .rule-events: signal and alert document types, shared base fields, episode fields, and the append-only data stream behavior.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6523/explore-analyze/alerting/experimental-alerting-system/rules/rule-event-field-reference
products:
  - Kibana
applies_to:
  - Elastic Cloud Serverless: Experimental
  - Elastic Stack: Planned
---

# Rule events in experimental alerting system
This page explains the two types of documents the experimental alerting system writes to `.rule-events` and how the data stream behaves, so you can write ES|QL queries against `.rule-events` with confidence, for example, to replay an episode's history, investigate a signal, or build dashboards from rule output.
<important>
  The `.rule-events` and `.alert-actions` data streams are [system indices](/elastic/docs-content/pull/6523/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/6523/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>


## Rule event documents

Each time a rule evaluates, Kibana writes one document per matched series to `.rule-events`. The `type` field determines the document kind:
- **`signal`** - A point-in-time record that the query matched. Useful for querying history or chaining into follow-on rules. Signal documents don't include `episode.*` fields.
- **`alert`** - A lifecycle-tracked episode visible in the alert inbox, episode details, and triage views. Alert documents include `episode.*` fields and represent a breach that stays open until the condition clears.

Both kinds share base fields. Only `alert` documents add episode fields that carry the lifecycle state for the matched series.
<note>
  The `.rule-events` data stream is append-only. A new document is written on every rule evaluation. Existing documents are never updated. Each document is a snapshot of that moment. The `episode.status` field records the lifecycle stage the episode was in at that evaluation. To view the full history of an episode, query `.rule-events` filtered by `episode.id`, for example:
  ```esql
  FROM .rule-events
  | WHERE episode.id == "<episode-id>"
  | SORT @timestamp ASC
  ```
</note>