elastic · nastasha-solomon · Aug 24, 2026 · Aug 5, 2026 · Aug 6, 2026 · Aug 7, 2026
@@ -27,7 +27,7 @@ stack: experimental 9.5+
 serverless: experimental
 ```
 
-The {{alerting-v2-system}} is built on {{esql}}. You write the query that defines what to watch for, choose how alert episodes are tracked per series, and control notifications through action policies that handle routing, frequency, and notification batching. The {{alerting-v2-system}} also adds alert episode lifecycle tracking, per-series snooze, and rules on alert episodes for correlation and escalation. It is a strong fit when you want full control over what data travels with each alert episode and how your team is notified.
+The {{alerting-v2-system}} is built on {{esql}}. You write the query that defines what to watch for, choose whether matches open tracked alert episodes or are recorded as signals, and control notifications through action policies that handle routing, frequency, and notification batching. The {{alerting-v2-system}} also adds alert episode lifecycle tracking, per-series snooze, queryable signal history, and rules that can correlate signals for escalation. It is a strong fit when you want full control over what data travels with each detection and how your team is notified.
 
 :::{note}
 The {{alerting-v2-system}} runs next to {{kib}} alerting on {{serverless-full}} and {{stack}} 9.5 and later. You don't have to move everything at once. You can copy or rebuild rules when you're ready, and your existing {{kib}} alerting rules won't be affected.

@@ -21,8 +21,9 @@ Elastic offers three alerting systems, each suited to different use cases and wo
 |---|---|---|
 | Monitor metrics, logs, or uptime with ready-made rules and no query language | [{{kib}} alerting](alerts.md) | {applies_to}`stack: ga` {applies_to}`serverless: ga` |
 | Use rules built for {{elastic-sec}}, {{observability}}, APM, or Maps | [{{kib}} alerting](alerts.md) | {applies_to}`stack: ga` {applies_to}`serverless: ga` |
-| Write {{esql}} to define exactly what to detect and what data each alert episode carries | [{{alerting-v2-system-cap}}](system-overview.md) | {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
-| Query alert history in Discover or build dashboards from alert data | [{{alerting-v2-system-cap}}](system-overview.md) | {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
+| Write {{esql}} to define exactly what to detect and what data each alert episode or signal carries | [{{alerting-v2-system-cap}}](system-overview.md) | {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
+| Record detections as signals for later analysis without opening episodes or sending notifications | [{{alerting-v2-system-cap}}](system-overview.md) | {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
+| Query alert and signal history in Discover or build dashboards from rule event data | [{{alerting-v2-system-cap}}](system-overview.md) | {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
 | Manage notification routing, grouping, and throttling in one place, reusable across rules | [{{alerting-v2-system-cap}}](system-overview.md) | {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
 | Build highly custom notification logic with reusable, configurable workflows | [{{alerting-v2-system-cap}}](system-overview.md) | {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
 | Build highly custom logic with scripting and chained inputs | [Watcher](watcher.md) | {applies_to}`stack: ga` {applies_to}`serverless: unavailable` |
@@ -33,7 +34,7 @@ Elastic offers three alerting systems, each suited to different use cases and wo
 |---|---|---|---|
 | **Best for** | Teams using built-in rule types with form-based setup | Teams that need full control over detection and notification routing | Custom alerting logic requiring scripting |
 | **Rule definition** | Select a rule type and fill in parameters | [Write an {{esql}} query](experimental-alerting-system/rules/configure-rule-query.md) or use a rule builder with form-based setup | Write a JSON watch definition |
-| **Alert data** | In-place updates, limited query support | [Append-only events queryable with {{esql}} in Discover](experimental-alerting-system/alerts/query-alerts-and-signals-in-discover.md) | Watch history index |
+| **Alert and signal data** | In-place updates, limited query support | Append-only [rule events](experimental-alerting-system/alerts/alert-data-model.md) for alert episodes and signals, [queryable with {{esql}} in Discover](experimental-alerting-system/alerts/query-alerts-and-signals-in-discover.md) | Watch history index |
 | **Notifications** | Configured per action on each rule | [Centralized action policies](experimental-alerting-system/notifications-actions.md), reusable across rules; supports action-level throttling and conditions | Action-level throttling and conditions |
 | **Noise reduction** | Snooze per rule or per alert, maintenance windows | Per-episode acknowledge or deactivate, per-series snooze, maintenance windows, match condition routing in [action policies](experimental-alerting-system/action-policies/reduce-notification-noise.md) | Action conditions and throttling |
 | **Available on {{serverless-full}}** | Yes | Yes, {applies_to}`serverless: experimental` | No |

@@ -14,7 +14,7 @@ An action policy is the gating layer between an alert episode and a workflow in
 
 ## Why action policies are separate from rules [policies-separate-from-rules]
 
-Action policies are independent of rules. A single action policy can cover alert episodes from many rules, so an action policy matching `severity: "critical"` applies regardless of which rule produced the alert episode. You can also update notification routing without touching any rule, and you can create rules without any action policy, which is useful for testing detection logic before wiring up notifications.
+Action policies are independent of rules. A single action policy can cover alert episodes from many rules, so an action policy matching `severity: "critical"` applies regardless of which rule produced the alert episode. You can create a rule without any action policy, which is useful for testing detection logic before wiring up notifications. You can also update notification routing later without touching the rule.
 
 To scope an action policy to one rule, use a matcher expression, for example `rule.id: "my-rule-id"`.
 

@@ -33,9 +33,9 @@ inactive → pending → active → recovering → inactive
 A checkout-latency rule runs every 5 minutes. It has an activation threshold of 2 consecutive breaches and a recovery threshold of 2 consecutive clears. The episode opens only after consecutive breaches meet the activation threshold and closes only after consecutive clears meet the recovery threshold. The system waits for confirmation in both directions.
 
 1. **14:00**: Routine check. p95 is within budget. No episode exists yet. The series is `inactive`.
-2. **14:05**: p95 jumps to 3.1s. The rule detects the first breach. The system creates the episode in `pending` and starts counting consecutive breaches.
+2. **14:05**: p95 jumps to 3.1s. The rule detects the first breach, creates the episode in `pending`, and starts counting consecutive breaches.
 3. **14:10**: p95 is still elevated. The second consecutive breach meets the activation threshold. The episode moves from `pending` to `active`. The system pages the engineer.
-4. **14:10–14:45**: Every evaluation finds high latency. The episode stays `active`. The system doesn't create new episodes. One episode tracks one problem, no matter how many times the rule evaluates while the condition holds.
+4. **14:10–14:45**: Every evaluation finds high latency. The episode stays `active`. The rule doesn't create new episodes. One episode tracks one problem, no matter how many times the rule evaluates while the condition holds.
 5. **14:50**: p95 drops back under 2s. The first clean check moves the episode from `active` to `recovering`. The system starts counting consecutive clears.
 6. **14:55**: A second consecutive clear meets the recovery threshold. The episode moves from `recovering` to `inactive`. The engineer receives a recovery notification.
 

@@ -41,7 +41,7 @@ These terms appear throughout the {{alerting-v2-system}} docs. If a term is uncl
 :   A label attached to alert episodes to indicate urgency. Severity is available as a filter in action policies so critical episodes can be routed differently from low-priority ones. To learn more, refer to [Configure rule severity](rules/configure-rule-severity.md).
 
 **Signal**
-:   A rule event recorded when a rule runs in Signal mode. Signals are stored and queryable in Discover, but they don't open an alert episode or trigger notifications. To learn more, refer to [Rule mode](rules/configure-rule-mode.md).
+:   A rule event recorded when a rule runs in Signal mode. Signals are stored in `.rule-events` and queryable in Discover, but they don't open an alert episode or trigger notifications. To learn more, refer to [Rule mode](rules/configure-rule-mode.md).
 
 **Threshold**
 :   The condition a rule uses to decide when something is worth alerting on, including how many times the condition must be met before an alert episode opens or closes. To learn more, refer to [Alert delay](rules/configure-rule-alert-delay.md) and [Recovery condition](rules/configure-rule-recovery.md).

@@ -15,13 +15,13 @@
 
 ## Rule runs in Alert mode [how-alert-mode-works]
 
-In Alert mode, the rule doesn't just record that a condition was found. It opens an alert episode that persists and tracks the problem until the condition clears. Each time the rule runs, it writes a rule event that can advance the episode's lifecycle state. An action policy sits between the episode and your team, deciding whether and when to trigger a workflow.
+In Alert mode, the rule doesn't just record that a condition was found. Each match causes the rule to open an alert episode that persists and tracks the problem until the condition clears. Each time the rule runs, it writes a rule event that can advance the episode's lifecycle state. An action policy sits between the episode and your team, deciding whether and when to trigger a workflow.
 
 | Step | Actor | Action |
 |------|-------|--------|
 | 1 | Rule | Runs on schedule and evaluates {{esql}} against your data |
 | 2 | Rule | Query returns results → A rule event is written to `.rule-events` |
-| 3 | System | Creates an alert episode and sets its initial state to `pending`; episode advances to `active` once the activation threshold is met |
+| 3 | Rule | Creates an alert episode and sets its initial state to `pending`; episode advances to `active` once the activation threshold is met |
 | 4 | Action policy | Evaluates the episode against its conditions (checks for episode eligibility, match conditions, and frequency) |
 | 5 | Action policy | If conditions are met, triggers a workflow |
 | 6 | Workflow | Sends notification or runs automation |
@@ -51,7 +51,7 @@
 |------|-------|--------|
 | 1 | Rule | Runs on schedule and evaluates {{esql}} against your data |
 | 2 | Rule | Query returns results → Writes a rule event (signal) to `.rule-events` |
-| 3 | System | Signal is immediately queryable in Discover, dashboards, and {{esql}} |
+| 3 | Rule | Signal is immediately queryable in Discover, dashboards, and {{esql}} |
 
 No alert episode is opened. No action policy evaluates the result. No notification is sent.
 

@@ -24,7 +24,7 @@ In Signal mode, each matching row is stored as a signal document with no alert l
 
 Rules only define *what* to detect. They don't control notifications, who gets notified, or when. That's the job of action policies, which are global objects scoped to your space that match alert episodes from any rule. A rule has no say in which action policies pick it up.
 
-This separation means you can build and test a rule without anyone getting paged, update notification routing without touching the rule, and have multiple action policies respond to the same rule independently.
+This separation means you can update notification routing without touching a rule, and have multiple action policies respond to the same rule independently.
 
 ## What to do next with rules [rules-next-steps]