diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
index cae78423d29..a3debbf8425 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md
@@ -80,7 +80,7 @@ In role management, features are organized into the following groups.
| Group | What it contains |
| --- | --- |
| **Analytics** | Privileges for the features you use to explore and visualize data. Refer to [Privileges in the Analytics group](#kibana-privileges-analytics). |
-| **Universal Alerting** {applies_to}`serverless: ga` {applies_to}`stack: experimental =9.5, ga 9.6+` | Privileges for {{alerting-v2-system}}. Refer to [Configure access to {{alerting-v2-system}}](/explore-analyze/alerting/esql/manage/configure-access.md).
{applies_to}`stack: experimental =9.5` In 9.5, this group is called **Alerting V2**. Before 9.5.4, it's called **Alerting**. |
+| **Universal Alerting** {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Privileges for {{alerting-v2-system}}. Refer to [Configure access to {{alerting-v2-system}}](/explore-analyze/alerting/esql/manage/configure-access.md). |
| **Elasticsearch** | Privileges for {{es}} features. |
| **Observability** | Privileges for Elastic {{observability}} features. Refer to [Observability {{kib}} privileges](/solutions/observability/get-started/observability-kibana-privileges.md). |
| **Security** | Privileges for {{elastic-sec}} features. Refer to [Security {{kib}} privileges](/solutions/security/manage/security-kibana-privileges.md). |
diff --git a/explore-analyze/alerting.md b/explore-analyze/alerting.md
index ea12f4fb6d9..a1919d2ab72 100644
--- a/explore-analyze/alerting.md
+++ b/explore-analyze/alerting.md
@@ -18,19 +18,19 @@ description: Watch your data and respond to conditions automatically with Elasti
Elastic alerting helps you watch your data and respond when something needs attention, whether that is a metric crossing a limit, an asset leaving an area on a map, or an unusual pattern in your time series. You set the conditions and how people should be notified. Elastic runs the checks for you.
-Elastic offers three alerting systems. If you're not sure which fits your situation, refer to [Compare alerting systems](alerting/compare-alerting-systems.md).
+Elastic offers more than one alerting system, and which ones you can use depends on your deployment type and version. If you're not sure which fits your situation, refer to [Compare alerting systems](alerting/compare-alerting-systems.md).
## {{alerting-v2-system-cap}}
```{applies_to}
serverless: ga
-stack: ga 9.6+, experimental =9.5
+stack: ga 9.6+
```
You write an {{esql}} query that defines what to watch for, decide whether matches are tracked as [alerts](alerting/esql/alerts.md) or recorded as rule events for later analysis, and control notifications through action policies that handle routing, frequency, and notification batching. {{alerting-v2-system-cap}} also adds alert lifecycle tracking, per-series snooze, queryable rule event history, and rules that can correlate those events 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}
-{{alerting-v2-system-cap}} runs next to {{alerting-v1-system}} 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 {{alerting-v1-system}} rules won't be affected.
+{{alerting-v2-system-cap}} runs next to {{alerting-v1-system}}, so you don't have to move everything at once. You can copy or rebuild rules when you're ready, and your existing {{alerting-v1-system}} rules won't be affected.
:::
[Get started with {{alerting-v2-system}} →](alerting/esql/system-overview.md)
diff --git a/explore-analyze/alerting/alerts.md b/explore-analyze/alerting/alerts.md
index c2b40c30c6e..6e3d9179d47 100644
--- a/explore-analyze/alerting/alerts.md
+++ b/explore-analyze/alerting/alerts.md
@@ -18,7 +18,7 @@ description: "Kibana Classic Alerting uses rules to check your data on a schedul
{{alerting-v1-system-cap}} lets you define rules that check your data on a schedule, create alerts when conditions are met, and trigger actions through connectors (email, Slack, webhooks, and more). It is available on all deployments.
:::{note}
-:applies_to: {"serverless": "ga", "stack": "ga 9.6+, experimental =9.5"}
+:applies_to: {"serverless": "ga", "stack": "ga 9.6+"}
Looking for {{alerting-v2-system}}? Refer to the [{{alerting-v2-system-cap}} overview](esql/system-overview.md) instead. The two systems are separate, so APIs and instructions for one don't apply to the other.
:::
diff --git a/explore-analyze/alerting/compare-alerting-systems.md b/explore-analyze/alerting/compare-alerting-systems.md
index e54b849e4bd..5e6a6058f18 100644
--- a/explore-analyze/alerting/compare-alerting-systems.md
+++ b/explore-analyze/alerting/compare-alerting-systems.md
@@ -13,10 +13,10 @@ description: Compare Kibana Classic Alerting, Kibana Universal Alerting, and Wat
# Compare alerting systems [compare-alerting-systems]
-Elastic offers three alerting systems, each suited to different use cases and workflows. Use this page to compare them by goal, feature, and availability.
+Elastic offers more than one alerting system, each suited to different use cases and workflows. Use this page to compare them by goal, feature, and availability.
:::{note}
-{{elastic-sec}} has its own detection rules, separate from these three systems. For threat detection, refer to [Detections and alerts](/solutions/security/detect-and-alert.md).
+{{elastic-sec}} has its own detection rules, separate from these alerting systems. For threat detection, refer to [Detections and alerts](/solutions/security/detect-and-alert.md).
:::
## Select by use case
@@ -24,11 +24,11 @@ Elastic offers three alerting systems, each suited to different use cases and wo
| Goal | Suggested system | Availability |
|---|---|---|
| Monitor metrics, logs, or uptime with ready-made rules and no query language | [{{alerting-v1-system-cap}}](alerts.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga` |
-| Write {{esql}} to define exactly what to detect and what data each rule event carries | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
-| Record matches as rule events with `type: signal` for later analysis, without sending notifications | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
-| Query rule event history in Discover or build dashboards from rule event data | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
-| Manage notification routing, grouping, and throttling in one place, reusable across rules | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
-| Build highly custom notification logic with reusable, configurable workflows | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+, experimental =9.5` |
+| Write {{esql}} to define exactly what to detect and what data each rule event carries | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
+| Record matches as rule events with `type: signal` for later analysis, without sending notifications | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
+| Query rule event history in Discover or build dashboards from rule event data | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
+| Manage notification routing, grouping, and throttling in one place, reusable across rules | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
+| Build highly custom notification logic with reusable, configurable workflows | [{{alerting-v2-system-cap}}](esql/system-overview.md) | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` |
| Build highly custom logic with scripting and chained inputs | [Watcher](watcher.md) | {applies_to}`stack: ga` {applies_to}`serverless: unavailable` |
## Compare at a glance
@@ -41,4 +41,4 @@ Elastic offers three alerting systems, each suited to different use cases and wo
| **Notifications** | Configured per action on each rule | [Action policies](esql/notifications-actions.md) invoke reusable workflows, which send the notification; policies support throttling and conditions | Action-level throttling and conditions |
| **Noise reduction** | Snooze per rule or per alert, maintenance windows | Acknowledge or deactivate per alert, per-series snooze, maintenance windows, match condition routing in [action policies](esql/action-policies/reduce-notification-noise.md) | Action conditions and throttling |
| **Available on {{serverless-full}}** | Yes | Yes, {applies_to}`serverless: ga` | No |
-| **Available on {{stack}}** | Yes | Yes, {applies_to}`stack: ga 9.6+, experimental =9.5` | Yes |
+| **Available on {{stack}}** | Yes | Yes, {applies_to}`stack: ga 9.6+` | Yes |
diff --git a/explore-analyze/alerting/esql/action-policies/about-action-policies.md b/explore-analyze/alerting/esql/action-policies/about-action-policies.md
index 5a613bf971f..d941a56b414 100644
--- a/explore-analyze/alerting/esql/action-policies/about-action-policies.md
+++ b/explore-analyze/alerting/esql/action-policies/about-action-policies.md
@@ -1,7 +1,7 @@
---
navigation_title: About action policies
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -27,7 +27,7 @@ Because of that separation, a single action policy can apply to alerts from many
To narrow which alerts an action policy applies to, set its [scope](create-configure-action-policy.md#matcher). An action policy with an empty scope applies to every eligible alert in the space.
-{applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` To apply an action policy to specific rules, give the policy and those rules the same [routing tag](create-configure-action-policy.md#routing-tags). A policy applies to alerts from every rule that has at least one of its routing tags, including rules you tag after you create the policy. The link doesn't depend on the rule's ID, name, or rule tags. You can rename a rule or reorganize its rule tags without changing which policies apply.
+To apply an action policy to specific rules, give the policy and those rules the same [routing tag](create-configure-action-policy.md#routing-tags). A policy applies to alerts from every rule that has at least one of its routing tags, including rules you tag after you create the policy. The link doesn't depend on the rule's ID, name, or rule tags. You can rename a rule or reorganize its rule tags without changing which policies apply.
## How action policies gate alerts [action-policy-gates]
@@ -36,8 +36,7 @@ A workflow runs only when the alert passes every gate. {{kib}} checks the gates
| Gate | What it checks |
|------|----------------|
| Alert eligibility | Whether the alert is acknowledged, snoozed, resolved, or in a maintenance window. Any of these stops it. |
-| Policy scope {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Whether the alert's rule has at least one of the policy's [routing tags](create-configure-action-policy.md#routing-tags), and whether the alert matches the policy's [KQL](../../../query-filter/languages/kql.md) expression. If the policy has both, the alert has to pass both. An empty scope passes every eligible alert in the space. |
-| Match conditions {applies_to}`stack: removed 9.6+, experimental =9.5` {applies_to}`serverless: unavailable` | Whether the alert matches the policy's [KQL](../../../query-filter/languages/kql.md) expression. An empty expression passes every eligible alert in the space. |
+| Policy scope | Whether the alert's rule has at least one of the policy's [routing tags](create-configure-action-policy.md#routing-tags), and whether the alert matches the policy's [KQL](../../../query-filter/languages/kql.md) expression. If the policy has both, the alert has to pass both. An empty scope passes every eligible alert in the space. |
| Frequency | Whether a workflow already ran for the alert's notification group within the policy's frequency interval. If it did, the alert waits. |
If any gate stops the alert, {{kib}} doesn't invoke a workflow for that action policy. Multiple action policies can apply to the same alert, and {{kib}} checks the gates separately for each one, with no precedence or merging between them.
diff --git a/explore-analyze/alerting/esql/action-policies/action-policy-reference.md b/explore-analyze/alerting/esql/action-policies/action-policy-reference.md
index 46d9adfe351..65b00ab2e9e 100644
--- a/explore-analyze/alerting/esql/action-policies/action-policy-reference.md
+++ b/explore-analyze/alerting/esql/action-policies/action-policy-reference.md
@@ -1,7 +1,7 @@
---
navigation_title: Action policy reference
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -18,43 +18,17 @@ Use the following fields in the **Match conditions** expression to filter which
| Field | Description | Example |
|---|---|---|
-| `alert_id` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Unique identifier of the alert. | `alert_id: "alert-001"`
Match a specific alert by ID. |
-| `episode_id` {applies_to}`stack: experimental =9.5` | Unique identifier of the alert. Replaced by `alert_id` in later versions. | `episode_id: "ep-001"`
Match a specific alert by ID. |
-| `alert_status` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Current lifecycle status of the alert. One of `inactive`, `pending`, `active`, or `recovering`. | `alert_status: "active"`
Match only active alerts. |
-| `episode_status` {applies_to}`stack: experimental =9.5` | Current lifecycle status of the alert. Replaced by `alert_status` in later versions. | `episode_status: "active"`
Match only active alerts. |
+| `alert_id` | Unique identifier of the alert. | `alert_id: "alert-001"`
Match a specific alert by ID. |
+| `alert_status` | Current lifecycle status of the alert. One of `inactive`, `pending`, `active`, or `recovering`. | `alert_status: "active"`
Match only active alerts. |
| `severity` | Current severity level. One of `info`, `low`, `medium`, `high`, or `critical`. Populated when the rule's {{esql}} query includes a `severity` column. Not set during recovery, so a severity-scoped policy applies only to open alerts. Severity can change during an alert without reopening it. The action policy picks up the new value on the next dispatcher cycle. For how to configure severity in a rule, refer to [Severity](../rules/configure-rule-severity.md). | `severity: "critical" OR severity: "high"`
Route high-priority alerts to a dedicated workflow. |
| `group_hash` | Stable hash identifying the alert series the alert belongs to. | `group_hash: "abc123"`
Match all alerts in a specific alert series. |
| `last_event_timestamp` | ISO 8601 timestamp of the most recent event recorded for the alert. | `last_event_timestamp > "2026-01-01"`
Match alerts with activity after a specific date. |
| `data.*` | Dynamic payload fields sent by the rule. Available fields depend on the rule type and configuration. Use for rule-specific fields not covered by the standard fields in this table. | `data.host.name: "web-01"`
Match alerts from a specific host in a host-based rule. |
:::{note}
-:applies_to: {"serverless": "ga", "stack": "ga 9.6+"}
To apply a policy to alerts from a set of rules, give the policy and those rules the same routing tag. **Match conditions** can't select alerts by the rule's ID, name, or tags. To learn more, refer to [Apply the policy to alerts from specific rules](create-configure-action-policy.md#routing-tags).
:::
-### Rule fields [action-policy-matcher-rule-fields]
-```{applies_to}
-stack: removed 9.6+, experimental =9.5
-serverless: unavailable
-```
-
-In addition to the alert fields, you can use the following fields in the **Match conditions** expression to select alerts by the rule that produced them.
-
-| Field | Description | Example |
-|---|---|---|
-| `rule.id` | Unique identifier of the rule that generated the alert. | `rule.id: "rule-001"`
Match alerts from one specific rule. |
-| `rule.name` | Display name of the rule. | `rule.name: "High CPU"`
Match alerts from rules with this display name. |
-| `rule.tags` | Tags attached to the rule. | `rule.tags: "payment-service"`
Match alerts from all rules with this tag. |
-
-:::{important}
-When you upgrade to a later version, action policies whose **Match conditions** use `rule.id`, `rule.name`, `rule.tags`, `episode_id`, or `episode_status` no longer select the alerts you expect. {{kib}} keeps the expression and doesn't show an error. A condition such as `rule.tags: "checkout"` stops matching any alert, so the policy stops invoking its workflows. A negated condition such as `NOT rule.tags: "checkout"` matches every alert.
-
-To fix these policies after you upgrade:
-
-1. Add the same routing tag to each policy and to its rules.
-2. Replace `episode_id` and `episode_status` with `alert_id` and `alert_status`.
-:::
-
## Notify per options [action-policy-notification-grouping]
Controls how the action policy batches alerts before invoking a workflow.
diff --git a/explore-analyze/alerting/esql/action-policies/common-action-policy-scenarios.md b/explore-analyze/alerting/esql/action-policies/common-action-policy-scenarios.md
index 22cc8b7fd6c..f2af0844cb8 100644
--- a/explore-analyze/alerting/esql/action-policies/common-action-policy-scenarios.md
+++ b/explore-analyze/alerting/esql/action-policies/common-action-policy-scenarios.md
@@ -1,7 +1,7 @@
---
navigation_title: Examples and common scenarios
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/action-policies/create-configure-action-policy.md b/explore-analyze/alerting/esql/action-policies/create-configure-action-policy.md
index 4d62081e03b..83b2356b5c0 100644
--- a/explore-analyze/alerting/esql/action-policies/create-configure-action-policy.md
+++ b/explore-analyze/alerting/esql/action-policies/create-configure-action-policy.md
@@ -1,7 +1,7 @@
---
navigation_title: Create an action policy
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -24,13 +24,9 @@ The policy's scope decides which alerts it applies to, and [frequency](#reduce-n
To narrow the scope of an action policy, use a [KQL expression](#filter-with-kql-expression).
-{applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` You can also use [routing tags](#routing-tags), on their own or with an expression. If you use both, the alert's rule has to have at least one of the routing tags and the alert has to match the expression.
+You can also use [routing tags](#routing-tags), on their own or with an expression. If you use both, the alert's rule has to have at least one of the routing tags and the alert has to match the expression.
### Apply the policy to alerts from specific rules [routing-tags]
-```{applies_to}
-serverless: ga
-stack: ga 9.6+
-```
To apply an action policy to a rule's alerts, give the policy and the rule the same routing tag. The policy applies to alerts from every rule that has at least one of its routing tags. If you add the tag to another rule later, the policy also applies to that rule's alerts, and you don't need to edit the policy.
@@ -51,15 +47,7 @@ To narrow the scope further, add a [match conditions expression](#filter-with-kq
Add a **Match conditions** [KQL](../../../query-filter/languages/kql.md) expression to narrow the policy to the alerts whose fields match it. For example, `severity: "critical"` applies the policy to critical alerts only. For the fields you can use, refer to [Match conditions fields](action-policy-reference.md#action-policy-matcher-fields).
-{applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` On a new action policy, expand **Advanced matching** to show **Match conditions**. The expression can use only the [match conditions fields](action-policy-reference.md#action-policy-matcher-fields), so it can't select alerts by the rule's ID, name, or tags. To apply the policy to specific rules, use [routing tags](#routing-tags).
-
-## Add tags to categorize the action policy [policy-tags]
-```{applies_to}
-stack: removed 9.6+, experimental =9.5
-serverless: unavailable
-```
-
-Tags are optional labels you assign to an action policy to categorize it or filter it in the **Action Policies** list. Action policy tags describe the action policy itself, not the alerts it applies to. You can add, edit, or remove tags at any time without affecting routing behavior.
+On a new action policy, expand **Advanced matching** to show **Match conditions**. The expression can use only the [match conditions fields](action-policy-reference.md#action-policy-matcher-fields), so it can't select alerts by the rule's ID, name, or tags. To apply the policy to specific rules, use [routing tags](#routing-tags).
## Set batching and frequency [reduce-noise-grouping]
@@ -98,10 +86,6 @@ In **Workflows**, search for a workflow by name and select it. Select as many as
If the workflow doesn't exist yet, select **Create a workflow** to build it in the **Workflows** app in a new tab, then return to the action policy and select it.
### Create an email or Slack workflow [inline-email-slack-workflow]
-```{applies_to}
-serverless: ga
-stack: ga 9.6+
-```
If all the action policy needs to do is send an email or post a Slack message, build that workflow in the action policy itself:
@@ -113,23 +97,11 @@ To put alert details in the message, reference the dispatcher payload with `{{in
{{kib}} creates a single-step workflow for each one when you save the action policy and attaches it as a destination. These are ordinary workflows, so you can open them in **Workflows** afterwards to edit them or attach them to another action policy. If the action policy fails to save, {{kib}} deletes the workflows it created for it.
-### Create a notification from the rule form [notification-from-rule-form]
-```{applies_to}
-stack: removed 9.6+, experimental =9.5
-serverless: unavailable
-```
-
-If you don't have a workflow ready, set up an email or Slack notification while you create a rule. When you save, {{kib}} creates the workflow and an action policy that matches that rule's alerts by `rule.id`.
-
## Link a rule to action policies [policies-that-match-a-rule]
To send a rule's alerts through an action policy that uses routing tags, add one of the policy's tags to the rule. To confirm which policies apply to a rule, check the rule's applied policies.
### Add routing tags to a rule [add-routing-tags]
-```{applies_to}
-serverless: ga
-stack: ga 9.6+
-```
To link a rule to an action policy, add one of the policy's routing tags to the rule. Only rules that open alerts can have routing tags. A rule that only writes rule events (`type: signal`) can't, because action policies don't evaluate those events.
@@ -146,21 +118,11 @@ When you create or edit a rule that opens alerts, the **Actions** step lists the
The list also indicates why each policy applies.
-::::{applies-switch}
-
-:::{applies-item} { serverless: ga, stack: ga 9.6+ }
To add a policy without leaving the rule, select **Create action policy** in **Applied policies**, then give the new policy one of the rule's routing tags. Each entry in **Applied policies** shows the connector types its workflows use, along with a badge or icon:
* A **Catch-all** badge means the policy has no routing tags and no expression, so it applies to alerts from every rule.
* A tag icon ({icon}`tag`) means the rule and the policy share routing tags. The tooltip lists them under **Matching routing tags**.
* An **Expression** badge means the policy also has a KQL expression. {{kib}} evaluates that expression against alert data when the policy runs, so the list can't confirm it in advance. A policy scoped by an expression alone doesn't appear in the list at all, but it can still apply once the rule opens an alert.
-:::
-
-:::{applies-item} stack: experimental =9.5
-The list covers policies whose **Match conditions** expression matches the rule's ID, name, or tags. Policies that match every rule appear under **Global policies**, and policies that match this rule in particular appear under **Matching global policies**.
-:::
-
-::::
## Related pages
diff --git a/explore-analyze/alerting/esql/action-policies/manage-action-policies.md b/explore-analyze/alerting/esql/action-policies/manage-action-policies.md
index 4d84751f5ec..37aee81b8a0 100644
--- a/explore-analyze/alerting/esql/action-policies/manage-action-policies.md
+++ b/explore-analyze/alerting/esql/action-policies/manage-action-policies.md
@@ -1,7 +1,7 @@
---
navigation_title: Manage action policies
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -20,7 +20,7 @@ The action policy list shows who created and last updated each policy, along wit
Deleting a rule doesn't delete the action policies that applied to its alerts. Delete those policies separately when no remaining rule needs them.
-{applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` To check which alerts a policy applies to, open the policy and read **Policy scope**. It lists the policy's [routing tags](create-configure-action-policy.md#routing-tags) and query. A policy with neither shows **This policy matches all alerts.** To list the rules that open alerts and have at least one of the policy's routing tags, select **See all affected rules**.
+To check which alerts a policy applies to, open the policy and read **Policy scope**. It lists the policy's [routing tags](create-configure-action-policy.md#routing-tags) and query. A policy with neither shows **This policy matches all alerts.** To list the rules that open alerts and have at least one of the policy's routing tags, select **See all affected rules**.
## Enable, disable, and snooze an action policy
diff --git a/explore-analyze/alerting/esql/action-policies/re-notification.md b/explore-analyze/alerting/esql/action-policies/re-notification.md
index cb600303e79..ced513d0d0b 100644
--- a/explore-analyze/alerting/esql/action-policies/re-notification.md
+++ b/explore-analyze/alerting/esql/action-policies/re-notification.md
@@ -1,7 +1,7 @@
---
navigation_title: Re-notification
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/action-policies/reduce-notification-noise.md b/explore-analyze/alerting/esql/action-policies/reduce-notification-noise.md
index cec77a80ae2..45ddbed1aa6 100644
--- a/explore-analyze/alerting/esql/action-policies/reduce-notification-noise.md
+++ b/explore-analyze/alerting/esql/action-policies/reduce-notification-noise.md
@@ -1,7 +1,7 @@
---
navigation_title: Reduce notification noise
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/action-policies/review-action-policy-execution-history.md b/explore-analyze/alerting/esql/action-policies/review-action-policy-execution-history.md
index 27d626c7a63..2c0a032c272 100644
--- a/explore-analyze/alerting/esql/action-policies/review-action-policy-execution-history.md
+++ b/explore-analyze/alerting/esql/action-policies/review-action-policy-execution-history.md
@@ -1,7 +1,7 @@
---
navigation_title: Review action policy execution history
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/action-policies/route-by-severity.md b/explore-analyze/alerting/esql/action-policies/route-by-severity.md
index 1431b148175..04b0c3239fb 100644
--- a/explore-analyze/alerting/esql/action-policies/route-by-severity.md
+++ b/explore-analyze/alerting/esql/action-policies/route-by-severity.md
@@ -1,7 +1,7 @@
---
navigation_title: Route by severity
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/action-policies/severity-escalation.md b/explore-analyze/alerting/esql/action-policies/severity-escalation.md
index 147240af39d..758cae3a5de 100644
--- a/explore-analyze/alerting/esql/action-policies/severity-escalation.md
+++ b/explore-analyze/alerting/esql/action-policies/severity-escalation.md
@@ -1,7 +1,7 @@
---
navigation_title: Severity escalation
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/alerts.md b/explore-analyze/alerting/esql/alerts.md
index 9d6950b6881..f809dc58627 100644
--- a/explore-analyze/alerting/esql/alerts.md
+++ b/explore-analyze/alerting/esql/alerts.md
@@ -1,7 +1,7 @@
---
navigation_title: Alerts
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/alerts/field-reference.md b/explore-analyze/alerting/esql/alerts/field-reference.md
index cf3e7b261a2..81db531000c 100644
--- a/explore-analyze/alerting/esql/alerts/field-reference.md
+++ b/explore-analyze/alerting/esql/alerts/field-reference.md
@@ -1,7 +1,7 @@
---
navigation_title: Field reference
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -47,10 +47,8 @@ When a user or the system records an action on an alert, {{kib}} writes a docume
| Field | Type | Description |
|---|---|---|
| `@timestamp` | date | When {{kib}} wrote this action document. |
-| `alert_id` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | keyword | ID of the alert. |
-| `episode_id` {applies_to}`stack: experimental =9.5` | keyword | ID of the alert. Replaced by `alert_id` in later versions. |
-| `alert_status` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | keyword | Lifecycle state of the alert at the time of this action. Can be one of the following: `inactive`, `pending`, `active`, `recovering`. |
-| `episode_status` {applies_to}`stack: experimental =9.5` | keyword | Lifecycle state of the alert at the time of this action. Replaced by `alert_status` in later versions. |
+| `alert_id` | keyword | ID of the alert. |
+| `alert_status` | keyword | Lifecycle state of the alert at the time of this action. Can be one of the following: `inactive`, `pending`, `active`, `recovering`. |
| `rule_id` | keyword | ID of the rule that owns the alert. |
| `group_hash` | keyword | Identifies the series the alert belongs to. |
| `action_type` | keyword | Identifies what happened and who initiated it. For more information, refer to [Action type values](#action-type-values). |
diff --git a/explore-analyze/alerting/esql/alerts/investigate-alert-episodes.md b/explore-analyze/alerting/esql/alerts/investigate-alert-episodes.md
index 0211ddab0bf..8ce4fc14967 100644
--- a/explore-analyze/alerting/esql/alerts/investigate-alert-episodes.md
+++ b/explore-analyze/alerting/esql/alerts/investigate-alert-episodes.md
@@ -1,7 +1,7 @@
---
navigation_title: Investigate alerts
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -12,7 +12,7 @@ description: "Investigate alerts. Understand what triggered an alert, assess met
From the **Alerts** page in {{alerting-v2-system}}, select an alert to open its detail page, which surfaces what triggered the alert, its severity, recurring patterns, and response history, so you can investigate and coordinate a response.
-{applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` Alerts from {{alerting-v1-system}} rules open a simpler flyout instead. Refer to [Investigate alerts from {{alerting-v1-system}}](#investigate-classic-alerts).
+Alerts from {{alerting-v1-system}} rules open a simpler flyout instead. Refer to [Investigate alerts from {{alerting-v1-system}}](#investigate-classic-alerts).
## Understand the trigger and scope [understand-trigger]
@@ -68,10 +68,6 @@ Use the **Open in Discover** action to view the full source documents instead of
If the rule has a runbook attached, you can view it directly from the alert to follow the documented triage steps.
## Investigate alerts from {{alerting-v1-system}} [investigate-classic-alerts]
-```{applies_to}
-serverless: ga
-stack: ga 9.6+
-```
Select an alert with **Classic** in the **Source** column to open its details flyout, then use its tabs to check the alert:
diff --git a/explore-analyze/alerting/esql/alerts/query-alerts-and-signals-in-discover.md b/explore-analyze/alerting/esql/alerts/query-alerts-and-signals-in-discover.md
index 9046e64eef4..78c911167b1 100644
--- a/explore-analyze/alerting/esql/alerts/query-alerts-and-signals-in-discover.md
+++ b/explore-analyze/alerting/esql/alerts/query-alerts-and-signals-in-discover.md
@@ -1,7 +1,7 @@
---
navigation_title: Query alert history
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -104,8 +104,6 @@ FROM .rule-events
{{kib}} writes one document to `.alert-actions` for every action a user or the system takes on an alert. Use it to audit who did what, measure acknowledgment response times, or check current snooze and assignment state. The following sections provide example queries for common scenarios.
-{applies_to}`stack: experimental =9.5` In {{stack}} 9.5, `.alert-actions` stores the alert ID and status as `episode_id` and `episode_status`. Replace `alert_id` and `alert_status` with those names in the following queries.
-
### View the full triage history for an alert [full-triage-history]
Returns all actions recorded for a single alert in chronological order. Use this to see the complete response sequence: who acknowledged it, whether a user snoozed it, and how it was eventually resolved. The **Resolve** action writes `deactivate`, and **Unresolve** writes `activate`.
diff --git a/explore-analyze/alerting/esql/alerts/query-signals.md b/explore-analyze/alerting/esql/alerts/query-signals.md
index 57e7521d406..ed0de8b2c45 100644
--- a/explore-analyze/alerting/esql/alerts/query-signals.md
+++ b/explore-analyze/alerting/esql/alerts/query-signals.md
@@ -1,7 +1,7 @@
---
navigation_title: Query rule events
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/alerts/rule-event-data-model.md b/explore-analyze/alerting/esql/alerts/rule-event-data-model.md
index a034b2c9959..d450b872a73 100644
--- a/explore-analyze/alerting/esql/alerts/rule-event-data-model.md
+++ b/explore-analyze/alerting/esql/alerts/rule-event-data-model.md
@@ -1,7 +1,7 @@
---
navigation_title: How Kibana stores rule events
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/alerts/triage-alert-episodes.md b/explore-analyze/alerting/esql/alerts/triage-alert-episodes.md
index 84589f15ace..983a73b0627 100644
--- a/explore-analyze/alerting/esql/alerts/triage-alert-episodes.md
+++ b/explore-analyze/alerting/esql/alerts/triage-alert-episodes.md
@@ -1,7 +1,7 @@
---
navigation_title: Triage alerts
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -55,7 +55,7 @@ Add context to an alert for filtering, routing, or ownership.
| Action | Description | Scope |
|---|---|---|
-| Edit alert tags or Edit Tags (depending on your {{stack}} version) | Adds or removes tags on the alert. | {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` Alert
{applies_to}`stack: experimental =9.5` Series |
+| Edit alert tags | Adds or removes tags on the alert. | Alert |
| Edit assignee | Assigns the alert to a specific user, so others know who owns the investigation. | Alert |
## Investigate the underlying data [investigate-underlying-data]
@@ -67,10 +67,6 @@ Go to Discover to check whether the data behind an alert shows a genuine problem
| Open in Discover | Opens the rule's base {{esql}} query scoped to the time window around when the alert opened. | Alert |
## Triage alerts from {{alerting-v1-system}} [triage-classic-alerts]
-```{applies_to}
-serverless: ga
-stack: ga 9.6+
-```
To act on alerts with **Classic** in the **Source** column, your role needs [privileges in both alerting systems](../manage/configure-access.md#alerting-classic-alert-privileges).
diff --git a/explore-analyze/alerting/esql/alerts/view-and-manage-alerts.md b/explore-analyze/alerting/esql/alerts/view-and-manage-alerts.md
index 14820279cd7..c6ce125df6d 100644
--- a/explore-analyze/alerting/esql/alerts/view-and-manage-alerts.md
+++ b/explore-analyze/alerting/esql/alerts/view-and-manage-alerts.md
@@ -1,7 +1,7 @@
---
navigation_title: View and manage alerts
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -12,7 +12,7 @@ description: "Monitor alerts with KPI panels, a histogram, and filters. Triage a
In {{alerting-v2-system}}, use the **Alerts** page to monitor alerts with KPI panels, a histogram, and filters. To open it, go to **Alerting** → **Alerts** in the {{observability}} navigation menu, or find **Alerts** using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
-{applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` The page also lists alerts from {{alerting-v1-system}} rules, so you can monitor and triage alerts from both systems in one table. Refer to [View alerts from both alerting systems](#alerts-from-both-systems).
+The page also lists alerts from {{alerting-v1-system}} rules, so you can monitor and triage alerts from both systems in one table. Refer to [View alerts from both alerting systems](#alerts-from-both-systems).
To silence, close, or tag alerts, refer to [Triage alerts](triage-alert-episodes.md). For alert lifecycle history, related alerts, and assignment, refer to [Investigate alerts](investigate-alert-episodes.md).
@@ -47,10 +47,6 @@ Narrow the time range when filters return too many results or tag options need r
:::
## View alerts from both alerting systems [alerts-from-both-systems]
-```{applies_to}
-serverless: ga
-stack: ga 9.6+
-```
To tell alerts from the two systems apart, check the **Source** column: **Universal** for {{alerting-v2-system}} or **Classic** for {{alerting-v1-system}}. To act on {{alerting-v1-system}} alerts from the **Alerts** page, refer to [Triage alerts from {{alerting-v1-system}}](triage-alert-episodes.md#triage-classic-alerts).
diff --git a/explore-analyze/alerting/esql/get-started.md b/explore-analyze/alerting/esql/get-started.md
index 8754f360ca9..86df4a1f466 100644
--- a/explore-analyze/alerting/esql/get-started.md
+++ b/explore-analyze/alerting/esql/get-started.md
@@ -1,7 +1,7 @@
---
navigation_title: Get started
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/get-started/create-your-first-rule.md b/explore-analyze/alerting/esql/get-started/create-your-first-rule.md
index abb4dc3d70d..03a5e3be3a6 100644
--- a/explore-analyze/alerting/esql/get-started/create-your-first-rule.md
+++ b/explore-analyze/alerting/esql/get-started/create-your-first-rule.md
@@ -1,7 +1,7 @@
---
navigation_title: Create your first rule
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -17,22 +17,14 @@ Here's what you'll do:
1. **Load sample data** - Create an index and populate it with synthetic latency data that moves through healthy, degraded, and recovered phases. This gives you a realistic dataset to work with without needing a live service.
2. **Write a detection query** - Use the query sandbox to build and preview an {{esql}} query that computes P95 latency and flags breaches. The sandbox lets you verify the logic before the rule ever runs.
-3. **Configure the rule** - Set the alert condition, schedule, lookback window, and recovery behavior. You'll see how each setting shapes the alert lifecycle.
+3. **Configure the rule** - Set the schedule, lookback window, alert delay, and recovery behavior. You'll see how each setting shapes the alert lifecycle.
4. **Confirm the rule is running** - Check the **Execution history** page to see that the rule is evaluating on schedule and its runs are succeeding.
5. **Watch the alert open and recover** - Open the alert's details page to watch the alert move from `pending` to `active` as the breach persists, then trigger the recovery condition directly to see it close.
## Requirements [create-rule-requirements]
-Before you start, make sure you have the following:
-
-- **One of the following deployment types**:
- - **{{serverless-short}}** - A {{serverless-full}} project. [Create a serverless project](/deploy-manage/deploy/elastic-cloud/serverless.md) if you don't have one.
- - **{{ech}}** - An {{ech}} deployment running version 9.5 or later. Refer to [Create an Elastic Cloud hosted deployment](/deploy-manage/deploy/elastic-cloud/create-an-elastic-cloud-hosted-deployment.md) if you don't have one.
- - **Self-managed** - An {{stack}} deployment running version 9.5 or later. Refer to the [local development quickstart](/deploy-manage/deploy/self-managed/local-development-installation-quickstart.md) if you don't have one.
-
-- **{{alerting-v2-system-cap}} turned on**: If {{alerting-v2-system}} is off, turn it on as described in [Set up {{alerting-v2-system}}](../setup.md#alerting-setup-turn-on).
-
-- **The required access**: Your role needs the privileges to create rules, triage alerts, and review execution history. Refer to [Configure access](../manage/configure-access.md#alerting-quick-reference). To create the tutorial index and load the sample data, your role also needs the `create_index` and `write` index privileges on `checkout-service-logs`.
+- An {{stack}} deployment or an {{observability}} project on {{serverless-short}}.
+- The [{{alerting-v2-system}} privileges](../manage/configure-access.md#alerting-quick-reference) to create rules, triage alerts, and view execution history, plus the `create_index` and `write` index privileges on `checkout-service-logs`.
## Prepare your environment [prepare-your-environment]
@@ -262,13 +254,15 @@ You'll build a rule that detects when P95 latency for a service exceeds 2 second
Go to **Alerting** → **Rules** in the {{observability}} navigation menu, or find **Rules** using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
-Then create a new rule, and select **Create ES|QL rule** to open the rule authoring flyout.
+Select **Create rule**, then select **ES|QL rule** to open the rule form.
::::
::::{step} Write and test the detection query
-1. Paste the following {{esql}} query into the **Query sandbox**. It finds the slowest 5% of requests for each service (P95 latency), labels how severe that is, and keeps only the services where that value is above 2 seconds. You don't need to add a time filter yourself. The sandbox and the rule both apply one automatically based on the date range or schedule you choose.
+1. In the **ES|QL query** section, select **Add query** to open the **Query sandbox**.
+
+2. Paste the following {{esql}} query into the sandbox. It finds the slowest 5% of requests for each service (P95 latency), labels how severe that is, and keeps only the services where that value is above 2 seconds. You don't need to add a time filter yourself. The sandbox and the rule both apply one automatically based on the date range or schedule you choose.
```esql
FROM checkout-service-logs
@@ -281,11 +275,11 @@ Then create a new rule, and select **Create ES|QL rule** to open the rule author
| WHERE p95_latency_ms > 2000
```
-2. Set the sandbox date range to **Today** and run the query. **Today** covers the full calendar day, so it finds the sample data no matter what time it is right now.
+3. Set the sandbox date range to **Today**, then select **Search** to run the query. **Today** covers the full calendar day, so it finds the sample data no matter what time it is right now.
-3. Confirm the query results. You should see one row for `service.name: checkout` with `p95_latency_ms` above 2000 and `severity: high` or `critical`.
+4. Confirm the query results. You should see one row for `service.name: checkout` with `p95_latency_ms` above 2000 and `severity: high` or `critical`.
-4. Select **Apply changes** to populate the rule form, then select **Next**.
+5. Select **Apply changes** to add the query to the rule form.
:::{note}
The sandbox time controls set the preview range only. They don't carry over to the rule's schedule or lookback window once the rule is running.
@@ -293,28 +287,31 @@ Then create a new rule, and select **Create ES|QL rule** to open the rule author
::::
-::::{step} Configure the alert condition
+::::{step} Set how the rule runs
-The query you applied from the sandbox auto-fills **Mode**, **Time field**, and **Group fields**. Set the remaining fields:
+On the **Condition** step, the query you applied fills in **Time field** with `@timestamp` and **Group fields** with `service.name`, the field in the query's `STATS ... BY` clause. Under **Rule execution**, set the following:
-- **Alert delay**: `Breaches: 2` (The breach must persist across 2 consecutive evaluations before the alert moves to `active`.)
-- **Schedule**: `Every 5 minutes`
-- **Lookback Window**: `Last 45 minutes` (Ensures the rule can reach the pre-loaded sample data regardless of when you complete the tutorial.)
+- **Schedule**: 5 minutes
+- **Lookback Window**: 45 minutes. This lets the rule reach the sample data no matter when you complete the tutorial.
Select **Next**.
::::
-::::{step} Configure the recovery condition
+::::{step} Set the alert and recovery behavior
-Confirm the default settings:
+1. On the **Outcome** step, keep **Detect and respond** selected for **What's your goal?** This option tracks each breach as an alert.
-- **Recovery**: `Default recovery`
-- **Recovery delay**: `Immediate` (no delay, recovers on first non-breach)
+2. Set **Alert delay** to **Breaches**, then set **Consecutive breaches** to `2`. The breach must persist across 2 consecutive evaluations before the alert moves to `active`.
-These default settings will produce the automatic recovery behavior this tutorial demonstrates. As soon as a scheduled run finds that the service's P95 latency is back under the 2-second threshold, the alert will close.
+3. Keep the default values for the remaining settings:
-Select **Next**.
+ - **Recovery**: **Default recovery**
+ - **Recovery delay**: **Immediate**
+
+ With these settings, the alert closes as soon as a scheduled run finds that the service's P95 latency is back under the 2-second threshold.
+
+4. Select **Next**.
::::
@@ -327,7 +324,7 @@ Select **Next**.
Select **Next**.
-2. On the **Actions** step, do not create an action policy (rules can run without notifications or an action policy configured). Select **Create rule** to create and enable the rule.
+2. On the **Actions** step, select **Create rule** to create and enable the rule. You don't need an action policy for this tutorial, because a rule can run without notifications.
::::
@@ -345,9 +342,9 @@ Open **Execution history** using the navigation menu or the [global search field
::::
-::::{step} Select the rule
+::::{step} Find the rule's runs
-On the **Rules** tab, select **Checkout Service Latency**.
+On the **Rules** tab, search for `Checkout Service Latency`.
::::
@@ -385,7 +382,7 @@ The degraded window starts at 16 minutes past the hour. Once the current UTC tim
::::{step} Inspect the alert details
-Select the alert to open its details. Use the metric trend to see how P95 latency compared to the threshold over the alert's lifetime, and confirm the grouping value (`checkout`) that triggered it.
+Select the alert to open its details. Use the **Trend** chart to see how P95 latency compared to the threshold over the alert's lifetime, and confirm the grouping value (`checkout`) that triggered it.
::::
diff --git a/explore-analyze/alerting/esql/get-started/glossary.md b/explore-analyze/alerting/esql/get-started/glossary.md
index f58edc3c049..60b2f1748c7 100644
--- a/explore-analyze/alerting/esql/get-started/glossary.md
+++ b/explore-analyze/alerting/esql/get-started/glossary.md
@@ -1,7 +1,7 @@
---
navigation_title: Glossary
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -31,7 +31,7 @@ These terms appear throughout the {{alerting-v2-system}} documentation.
**Notification**
: The message or action a workflow sends (such as a Slack message, an email, or a webhook call) when an alert matches an action policy or a lifecycle trigger fires. To learn more, refer to [How the dispatcher evaluates action policies](../action-policies/about-action-policies.md#how-action-policies-evaluated).
-**Routing tag** {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+`
+**Routing tag**
: A tag that links rules to an action policy. When a rule and an action policy share a routing tag, the policy applies to that rule's alerts. Routing tags are separate from rule tags, which only label and filter rules. To learn more, refer to [Apply the policy to alerts from specific rules](../action-policies/create-configure-action-policy.md#routing-tags).
**Rule**
diff --git a/explore-analyze/alerting/esql/get-started/how-it-works.md b/explore-analyze/alerting/esql/get-started/how-it-works.md
index aacc3706bad..113a7113829 100644
--- a/explore-analyze/alerting/esql/get-started/how-it-works.md
+++ b/explore-analyze/alerting/esql/get-started/how-it-works.md
@@ -1,7 +1,7 @@
---
navigation_title: How it works
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -45,7 +45,7 @@ After a few weeks, the accumulated events become useful in two ways. The team ca
## Related pages
-- [Set up {{alerting-v2-system}}](../setup.md): Check the requirements and turn the system on or off.
+- [Set up {{alerting-v2-system}}](../setup.md): Check the requirements and turn on optional features.
- [Create your first rule](create-your-first-rule.md): Load sample data, create a rule, and observe the alert lifecycle.
- [Rules](../rules.md): What rules detect, how action policies invoke workflows, and how to select a creation path.
- [Notifications and actions](../notifications-actions.md): Set up action policies that invoke workflows for the alerts they apply to.
diff --git a/explore-analyze/alerting/esql/manage.md b/explore-analyze/alerting/esql/manage.md
index eb59703d8d3..85c67a49a76 100644
--- a/explore-analyze/alerting/esql/manage.md
+++ b/explore-analyze/alerting/esql/manage.md
@@ -1,7 +1,7 @@
---
navigation_title: Manage
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/manage/authorization.md b/explore-analyze/alerting/esql/manage/authorization.md
index 867b7bd7b60..e0b0009835c 100644
--- a/explore-analyze/alerting/esql/manage/authorization.md
+++ b/explore-analyze/alerting/esql/manage/authorization.md
@@ -1,7 +1,7 @@
---
navigation_title: Authorization
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/manage/configure-access.md b/explore-analyze/alerting/esql/manage/configure-access.md
index 05a4c933f14..36127a0f0cc 100644
--- a/explore-analyze/alerting/esql/manage/configure-access.md
+++ b/explore-analyze/alerting/esql/manage/configure-access.md
@@ -1,7 +1,7 @@
---
navigation_title: Configure access
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -13,8 +13,6 @@ description: "Kibana feature privileges and Elasticsearch index privileges neede
To create rules, triage alerts, and configure notifications in {{alerting-v2-system}}, your role needs specific {{kib}} feature privileges and, if you're querying alerting data in Discover, {{es}} index privileges. [Create or update a role](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-role-management.md) and add the privileges that match the tasks your team performs.
-Most privileges are under the **Universal Alerting** or **Alerting V2** category (depending on your {{stack}} version and deployment type) in {{kib}} role management.
-
:::{note}
Depending on how your rules and notifications are configured, your role might also need `read` index privileges on the indices their rules query and **Actions and Connectors: All** (under **Management**) to create or edit workflow connectors. Refer to [{{kib}} role management](/deploy-manage/users-roles/cluster-or-deployment-auth/kibana-role-management.md) for guidance on building roles that combine privileges across features.
:::
@@ -29,7 +27,7 @@ The following table shows the minimum privileges for each activity. Higher privi
| Monitor rule execution | **Execution history: Read** (under **Universal Alerting**) |
| Triage alerts | **Alerts: All** (under **Universal Alerting**) |
| Configure notifications | **Action Policies: All** (under **Universal Alerting**) + **Workflows: Read** (under **Analytics** → **Workflows**) |
-| Create rules and action policies with {{agent-builder}} {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` | **{{agent-builder}}: Read** (under **Analytics**) + the privileges to [save what the agent creates](#alerting-agent-builder-privileges) |
+| Create rules and action policies with {{agent-builder}} {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.6+` | **{{agent-builder}}: Read** (under **Analytics**) + the privileges to [save what the agent creates](#alerting-agent-builder-privileges) |
| Query `.rule-events` and `.alert-actions` in Discover | **Discover: Read** (under **Analytics** → **Discover**) + **Alerts: Read** (Elasticsearch `read` access is bundled automatically) |
| Query `.kibana-event-log-*` in Discover | **Discover: Read** (under **Analytics** → **Discover**) + custom role with `read` index privilege on `.kibana-event-log-*` |
@@ -67,11 +65,6 @@ Both levels also grant read access to the alert data streams. Refer to [{{es}} i
### Alerts from {{alerting-v1-system}} [alerting-classic-alert-privileges]
-```{applies_to}
-serverless: ga
-stack: ga 9.6+
-```
-
The **Alerts** page also lists {{alerting-v1-system}} alerts. Your role's {{alerting-v1-system}} privileges for each alert's rule type decide which of these alerts you can see and act on:
- **To view an alert**: Your role must be able to view alerts from the alert's rule type in {{alerting-v1-system}}.
@@ -109,7 +102,7 @@ Action policies invoke workflows, which send notifications. The **Workflows** pr
```{applies_to}
serverless: experimental
-stack: experimental 9.5+
+stack: experimental 9.6+
```
To create rules and action policies with [{{agent-builder}}](../rules/create-rules-action-policies-agent-builder.md), your role needs these privileges:
diff --git a/explore-analyze/alerting/esql/notifications-actions.md b/explore-analyze/alerting/esql/notifications-actions.md
index 1cfd39f0564..49fb6181d52 100644
--- a/explore-analyze/alerting/esql/notifications-actions.md
+++ b/explore-analyze/alerting/esql/notifications-actions.md
@@ -1,7 +1,7 @@
---
navigation_title: Notifications and actions
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -24,7 +24,7 @@ To send a notification or trigger an action from a rule in {{alerting-v2-system}
2. [Create an action policy](action-policies/create-configure-action-policy.md) that routes alerts to that workflow. The action policy controls which alerts qualify, how they batch, and how often it invokes the workflow.
- {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` To apply the policy to specific rules, give the policy and those rules the same [routing tag](action-policies/create-configure-action-policy.md#routing-tags).
+ To apply the policy to specific rules, give the policy and those rules the same [routing tag](action-policies/create-configure-action-policy.md#routing-tags).
To run a workflow when a user acts on an alert, such as opening a ticket when someone assigns it, use an [alert lifecycle trigger](../../workflows/triggers/event-driven-triggers.md#alert-episode-lifecycle-triggers-event-driven) instead. For a comparison, refer to [Connect workflows](workflows-alerting.md#when-to-use-action-policies-lifecycle-triggers).
diff --git a/explore-analyze/alerting/esql/rules.md b/explore-analyze/alerting/esql/rules.md
index 950627d9755..1ee98f0ff2f 100644
--- a/explore-analyze/alerting/esql/rules.md
+++ b/explore-analyze/alerting/esql/rules.md
@@ -1,7 +1,7 @@
---
navigation_title: Rules
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/configure-a-rule.md b/explore-analyze/alerting/esql/rules/configure-a-rule.md
index 4cd9b08defb..1d896166c19 100644
--- a/explore-analyze/alerting/esql/rules/configure-a-rule.md
+++ b/explore-analyze/alerting/esql/rules/configure-a-rule.md
@@ -1,7 +1,7 @@
---
navigation_title: Configure a rule
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -23,4 +23,4 @@ description: "Overview of configurable rule settings: required settings (mode, q
| [Recovery condition](configure-rule-recovery.md) | Whether an alert closes automatically, and how much confirmation it needs before it does. Only when matches are grouped into an alert. | Optional |
| [No-data handling](configure-no-data-handling.md) | What the rule records when the base query returns no results. Only when matches are grouped into an alert. | Optional |
| [Tags, runbooks, and dashboards](configure-rule-artifacts.md) | Labels, investigation guides, and linked dashboards attached to the rule. Tags and runbooks apply only when matches are grouped into an alert. Dashboards apply to any rule. | Optional |
-| [Routing tags](../action-policies/create-configure-action-policy.md#add-routing-tags) {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | Tags that link the rule's alerts to action policies with the same tag. Only when matches are grouped into an alert. | Optional |
+| [Routing tags](../action-policies/create-configure-action-policy.md#add-routing-tags) | Tags that link the rule's alerts to action policies with the same tag. Only when matches are grouped into an alert. | Optional |
diff --git a/explore-analyze/alerting/esql/rules/configure-no-data-handling.md b/explore-analyze/alerting/esql/rules/configure-no-data-handling.md
index 53b16ba5919..200b3c0435c 100644
--- a/explore-analyze/alerting/esql/rules/configure-no-data-handling.md
+++ b/explore-analyze/alerting/esql/rules/configure-no-data-handling.md
@@ -1,7 +1,7 @@
---
navigation_title: No-data handling
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -12,17 +12,10 @@ description: "How to configure the no-data strategy for rules: hold the last kno
No-data handling is an optional setting for {{alerting-v2-system}} rules that group matches into an alert. It controls what the rule does when it can't tell whether an alert has genuinely recovered or the data just stopped showing up. Setting this correctly prevents false recoveries and misleading `no_data` events when data sources stop reporting. In the rule form, the setting is **No data behavior**.
-In YAML, set no-data handling with these settings:
-
-* {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` The `no_data` object.
-* {applies_to}`stack: experimental =9.5` The `no_data_strategy` field.
+In YAML, set no-data handling with the `no_data` object.
## How no-data handling fits into recovery [no-data-and-recovery]
-::::::{applies-switch}
-
-:::::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
When a breached group stops matching, the rule runs a presence query to check whether the group still has data. By default, the presence query is the [base query](configure-rule-query.md#query-base). To use a different query, set `no_data.query`.
* **Group still has data**: The group isn't missing, so the rule treats this as a genuine [recovery](configure-rule-recovery.md) rather than a data gap. With **Custom recovery**, the alert recovers when the recovery condition matches. If the group has data but the condition doesn't match, the alert stays open.
@@ -35,49 +28,16 @@ If **No data behavior** is **Do nothing**, the rule skips the presence query. Wi
**No data behavior** applies with any recovery option. With **No recovery**, the rule never recovers an alert on its own, but **Recover immediately** can still close an alert when its group has no data.
To use **Keep last known status** or **Recover immediately**, the rule needs an alert condition or a no-data query. Without one, a group that stops breaching looks the same as a group that has no data.
-:::::
-
-:::::{applies-item} stack: experimental =9.5
-
-When a breached group stops matching, the rule re-runs the [base query](configure-rule-query.md#query-base) to confirm the group is actually gone before recovering the alert:
-
-* **Group still there** - The base query still returns the group, confirming this is a genuine [recovery](configure-rule-recovery.md) rather than a data gap.
-* **Group missing too** - The base query returns nothing for the group either, so the rule can't tell whether the problem actually cleared up or the data source just stopped reporting. What happens next depends on how you've configured `no_data_strategy`.
-
-The check described above is part of the recovery process, so it only runs when `recovery_strategy` is **Default recovery** or **Custom recovery**.
-
-If `recovery_strategy` is **No recovery** instead, alerts stay open until someone closes them manually, the base-query check above doesn't run, and `no_data_strategy` has no effect.
-:::::
-
-::::::
## No-data strategy options [no-data-strategy-options]
Choose one of the following options in the **No data behavior** field. Each maps to a strategy value if you're editing YAML directly.
-::::{applies-switch}
-
-:::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
| Option | `no_data.strategy` value | Description |
| --- | --- | --- |
| Keep last known status | `keep_last` | Hold the last known lifecycle state. An active breach stays active and a recovered alert stays recovered. |
| Recover immediately | `resolve` | Close the alert the first time the rule finds no data for the group. |
| Do nothing | `ignore` | Skip the no-data check. With **Default recovery**, a group that stops matching recovers, but the rule doesn't confirm that the data pipeline is actually working. This is the default. |
-:::
-
-:::{applies-item} stack: experimental =9.5
-
-| Option | `no_data_strategy` value | Description |
-| --- | --- | --- |
-| Keep last known status | `last_known_status` | Hold the last known lifecycle state. An active breach stays active and a recovered alert stays recovered. |
-| Recover | `recover` | Treat absence as recovery. |
-| Do nothing | `none` | Skip the no-data check. An empty result is treated the same as **Recover**, but the rule doesn't confirm that the data pipeline is actually working. |
-:::
-
-::::
-
-{applies_to}`stack: experimental =9.5` `no_data_strategy` only triggers when the base query returns **zero rows**. If one host or data source goes quiet but others keep reporting, the query still returns rows for the ones still reporting, so `no_data_strategy` won't trigger. To catch a single silent source in that situation, use the {{esql}} pattern in [No-data detection](esql-no-data-detection.md), which turns a silent source into its own alert row.
## When to configure no-data handling [no-data-when-to-use]
@@ -100,10 +60,7 @@ Create a rule that monitors infrastructure CPU. Set **No data behavior** to **Ke
### Close the alert when a queue empties out
-Create a rule that monitors how many jobs are waiting in a queue and opens an alert when the backlog gets too large. To close the alert once the queue is empty and the query has nothing to return, set **No data behavior** to one of these options:
-
-* {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` **Recover immediately** (`resolve`)
-* {applies_to}`stack: experimental =9.5` **Recover** (`recover`)
+Create a rule that monitors how many jobs are waiting in a queue and opens an alert when the backlog gets too large. To close the alert once the queue is empty and the query has nothing to return, set **No data behavior** to **Recover immediately** (`resolve`).
## Related pages
diff --git a/explore-analyze/alerting/esql/rules/configure-rule-alert-delay.md b/explore-analyze/alerting/esql/rules/configure-rule-alert-delay.md
index 77b6f23f89a..8cbbc28bbf3 100644
--- a/explore-analyze/alerting/esql/rules/configure-rule-alert-delay.md
+++ b/explore-analyze/alerting/esql/rules/configure-rule-alert-delay.md
@@ -1,7 +1,7 @@
---
navigation_title: Alert delay
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -12,10 +12,7 @@ description: "Configure alert delay for rules that group matches into an alert,
Alert delay is an optional setting for {{alerting-v2-system}} rules that group matches into an alert. It controls when a breached rule transitions from pending to active, reducing noise from brief spikes that don't reflect a real state change.
-In YAML, alert delay corresponds to these settings:
-
-* {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` The `state_transition.pending` object.
-* {applies_to}`stack: experimental =9.5` The `state_transition.pending_*` fields.
+In YAML, alert delay corresponds to the `state_transition.pending` object.
## When to configure alert delay [alert-delay-when-to-use]
@@ -41,10 +38,6 @@ Leave alert delay set to **Immediate** when:
Use the following fields to configure the Breaches and Duration modes. Timeframe fields accept duration strings between `5s` and `365d`. Refer to [Duration format](yaml-rule-schema-reference.md#duration-format) for supported units.
-:::::{applies-switch}
-
-::::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
| Field | Type | Accepted values | Description |
| --- | --- | --- | --- |
| `state_transition.pending.count` | integer | 0–1000 | Consecutive matches the alert spends in `pending` before it becomes `active` on the next match. For example, `2` opens the alert on the third consecutive match. Appears as **Consecutive breaches** in Breaches mode. Set to `0` to open the alert on the first match. |
@@ -52,24 +45,6 @@ Use the following fields to configure the Breaches and Duration modes. Timeframe
| `state_transition.pending.operator` | string | `and` or `or` | When you set both `count` and `timeframe`, controls whether both must be satisfied (`and`) or either one is enough (`or`). Defaults to `or`. |
You can combine Breaches and Duration by setting both `count` and `timeframe`. Use `operator: and` to require both conditions before the alert opens, or `operator: or` if either condition alone is enough. For field details, refer to the [YAML rule schema reference](yaml-rule-schema-reference.md#state-transition-fields).
-::::
-
-::::{applies-item} stack: experimental =9.5
-
-:::{note}
-In the YAML rule schema, these fields are prefixed with `state_transition.`. For example, `pending_count` here is `state_transition.pending_count` in the [YAML rule schema reference](yaml-rule-schema-reference.md#state-transition-fields). They are the same fields.
-:::
-
-| Field | Type | Accepted values | Description |
-| --- | --- | --- | --- |
-| `pending_count` | integer | 0–1000 | Number of consecutive breach evaluations required before the alert opens. Appears as **Consecutive breaches** in Breaches mode. Set to `0` to skip the pending phase and transition directly to active on the first breach. |
-| `pending_timeframe` | duration | Any duration string | How long the condition must remain breached before the alert opens. Appears as **Active for** in Duration mode. |
-| `pending_operator` | string | `AND` or `OR` | When both `pending_count` and `pending_timeframe` are set, controls whether both must be satisfied (`AND`) or either one is enough (`OR`). |
-
-You can combine Breaches and Duration by setting both `pending_count` and `pending_timeframe`. Use `pending_operator: AND` to require both conditions before the alert opens, or `pending_operator: OR` if either condition alone is enough.
-::::
-
-:::::
:::{note}
Looking for the equivalent delay before an alert closes? Refer to [Recovery condition](configure-rule-recovery.md#recovery-delay).
@@ -85,10 +60,6 @@ Create a rule that monitors CPU usage and runs every minute. A single high readi
Create a rule that monitors a payment error rate. Brief spikes happen during deployments and are expected. Set a count of `5` and a timeframe of `2m`, and require both. The rule only fires when the error rate has breached on 5 consecutive evaluations and has been continuously elevated for at least 2 minutes. Either condition alone isn't enough.
-::::{applies-switch}
-
-:::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
```yaml
state_transition:
pending:
@@ -96,19 +67,6 @@ state_transition:
timeframe: 2m
operator: and
```
-:::
-
-:::{applies-item} stack: experimental =9.5
-
-```yaml
-state_transition:
- pending_count: 5
- pending_timeframe: 2m
- pending_operator: AND
-```
-:::
-
-::::
## Related pages
diff --git a/explore-analyze/alerting/esql/rules/configure-rule-artifacts.md b/explore-analyze/alerting/esql/rules/configure-rule-artifacts.md
index cb9dac8e326..d27e3343846 100644
--- a/explore-analyze/alerting/esql/rules/configure-rule-artifacts.md
+++ b/explore-analyze/alerting/esql/rules/configure-rule-artifacts.md
@@ -1,7 +1,7 @@
---
navigation_title: Tags, runbooks, and dashboards
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -15,10 +15,7 @@ Tags, runbooks, and related dashboards are optional artifacts you attach to a {{
## When to add artifacts [artifacts-when-to-use]
Tags
-: Free-form labels for filtering and organization. Add them to filter alerts on the **Alerts** page or to mark which team owns a rule.
-
- * {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` Tags don't affect which action policies apply. To link a rule to action policies, add [routing tags](../action-policies/create-configure-action-policy.md#add-routing-tags) in the **Actions** step instead.
- * {applies_to}`stack: removed 9.6+, experimental =9.5` {applies_to}`serverless: unavailable` Alerts inherit tags, so any tag on the rule is available as a KQL matcher in action policies.
+: Free-form labels for filtering and organization. Add them to filter alerts on the **Alerts** page or to mark which team owns a rule. Tags don't affect which action policies apply. To link a rule to action policies, add [routing tags](../action-policies/create-configure-action-policy.md#add-routing-tags) in the **Actions** step instead.
Runbooks
: An investigation guide stored with the rule. Add one when responders who don't know the service need triage steps next to the alert, or when the response should stay consistent.
@@ -45,9 +42,8 @@ To link dashboards, your role needs the [privileges to manage rules](../manage/c
1. Go to **Alerting** → **Rules** in the {{observability}} navigation menu, or find **Rules** using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). Then select the rule.
2. On the **Overview** tab, expand **Artifacts**.
-3. In the **Dashboards** section:
- * {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` Select **Attach related dashboards**. Search for a dashboard. Results are grouped into **Attached** and **Other dashboards**. Select the dashboards to link, then select **Save**. This updates the rule right away.
- * {applies_to}`stack: experimental =9.5` Select **Manage linked dashboards**. In **Related dashboards**, search for a dashboard and select it, then save the rule.
+3. In the **Dashboards** section, select **Attach related dashboards**, then search for a dashboard. Results are grouped into **Attached** and **Other dashboards**.
+4. Select the dashboards to link, then select **Save**. This updates the rule right away.
To remove a link, select the remove icon next to the dashboard, then select **Remove** to confirm. Removing a link updates the rule right away. This removes the link only. The dashboard itself is unaffected.
diff --git a/explore-analyze/alerting/esql/rules/configure-rule-grouping.md b/explore-analyze/alerting/esql/rules/configure-rule-grouping.md
index 7ba6959cc8d..7aafa51214c 100644
--- a/explore-analyze/alerting/esql/rules/configure-rule-grouping.md
+++ b/explore-analyze/alerting/esql/rules/configure-rule-grouping.md
@@ -1,7 +1,7 @@
---
navigation_title: Grouping
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/configure-rule-mode.md b/explore-analyze/alerting/esql/rules/configure-rule-mode.md
index 4627a2e1f8a..9935fc40dcd 100644
--- a/explore-analyze/alerting/esql/rules/configure-rule-mode.md
+++ b/explore-analyze/alerting/esql/rules/configure-rule-mode.md
@@ -1,7 +1,7 @@
---
navigation_title: Rule mode
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/configure-rule-query.md b/explore-analyze/alerting/esql/rules/configure-rule-query.md
index 2d1b9b99989..5a1c27926f6 100644
--- a/explore-analyze/alerting/esql/rules/configure-rule-query.md
+++ b/explore-analyze/alerting/esql/rules/configure-rule-query.md
@@ -1,7 +1,7 @@
---
navigation_title: ES|QL query
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/configure-rule-recovery.md b/explore-analyze/alerting/esql/rules/configure-rule-recovery.md
index 1111701069e..91a6e35f19c 100644
--- a/explore-analyze/alerting/esql/rules/configure-rule-recovery.md
+++ b/explore-analyze/alerting/esql/rules/configure-rule-recovery.md
@@ -1,7 +1,7 @@
---
navigation_title: Recovery condition
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -16,10 +16,6 @@ Recovery condition settings are optional for {{alerting-v2-system}} rules that g
Choose one of the following options in the **Recovery** field. Each maps to a recovery strategy value if you're editing YAML directly.
-:::::{applies-switch}
-
-::::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
| Option | `recovery.strategy` value | Description |
| --- | --- | --- |
| Default recovery | `no_breach` | Recovers an alert when its group no longer breaches. If you set **No data behavior** to anything other than **Do nothing**, {{kib}} also checks that the group still has data. That confirms the group is actually healthy, not just missing from the data. This is the default and covers most rules. |
@@ -31,22 +27,6 @@ The rule form doesn't offer the `query` strategy, which evaluates an independent
:::{note}
If you omit `recovery` in the YAML editor of the rule form, {{kib}} uses **Default recovery**.
:::
-::::
-
-::::{applies-item} stack: experimental =9.5
-
-| Option | `recovery_strategy` value | Description |
-| --- | --- | --- |
-| Default recovery | `no_breach` | Recovers an alert when its group no longer breaches and the base query (without the alert condition) still returns that group. That confirms the group is actually healthy, not just missing from the data. This is the default and covers most rules. |
-| Custom recovery | `query` | Evaluates a separate recovery condition. A match recovers the alert. No match falls back to the same base-query check as **Default recovery**. |
-| No recovery | `none` | Turns off automatic recovery entirely. Alerts stay open until closed manually. With recovery turned off, no-data handling doesn't run either. |
-
-:::{note}
-An unset `recovery_strategy` behaves the same as **No recovery**, but unset usually means the setting was overlooked rather than a deliberate choice.
-:::
-::::
-
-:::::
An empty base query result triggers [no-data handling](configure-no-data-handling.md) for rules using **Default recovery** or **Custom recovery**.
@@ -76,10 +56,6 @@ Recovery delay controls how much confirmation the rule needs, once the recovery
### Recovery delay fields
-:::::{applies-switch}
-
-::::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
| Field | Type | Accepted values | Description |
| --- | --- | --- | --- |
| `state_transition.recovering.count` | integer | 0–1000 | Consecutive recoveries the alert spends in `recovering` before it becomes `inactive` on the next recovery. Set to `0` to close the alert on the first recovery. |
@@ -91,26 +67,6 @@ Timeframe fields accept duration strings between `5s` and `365d`. Refer to [Dura
A rule with **No recovery** (`manual`) can't set `state_transition.recovering`, because a recovery delay has no effect when alerts never recover on their own.
You can combine Recoveries and Duration by setting both `count` and `timeframe`. Use `operator: and` to require both conditions before the alert closes, or `operator: or` if either condition alone is enough. For field details, refer to the [YAML rule schema reference](yaml-rule-schema-reference.md#state-transition-fields).
-::::
-
-::::{applies-item} stack: experimental =9.5
-
-| Field | Type | Accepted values | Description |
-| --- | --- | --- | --- |
-| `recovering_count` | integer | 0–1000 | Number of consecutive non-breaching evaluations required before the alert closes. Set to `0` to skip the recovering phase and transition directly to inactive on recovery. |
-| `recovering_timeframe` | duration | Any duration string | How long the condition must remain non-breaching before the alert closes. |
-| `recovering_operator` | string | `AND` or `OR` | When both `recovering_count` and `recovering_timeframe` are set, controls whether both must be satisfied (`AND`) or either one is enough (`OR`). |
-
-Timeframe fields accept duration strings between `5s` and `365d`. Refer to [Duration format](yaml-rule-schema-reference.md#duration-format) for supported units.
-
-:::{note}
-In the YAML rule schema, these fields are prefixed with `state_transition.`. For example, `recovering_count` here is `state_transition.recovering_count` in the [YAML rule schema reference](yaml-rule-schema-reference.md#state-transition-fields). They are the same fields.
-:::
-
-You can combine Recoveries and Duration by setting both `recovering_count` and `recovering_timeframe`. Use `recovering_operator: AND` to require both conditions before the alert closes, or `recovering_operator: OR` if either condition alone is enough.
-::::
-
-:::::
## Examples
diff --git a/explore-analyze/alerting/esql/rules/configure-rule-schedule.md b/explore-analyze/alerting/esql/rules/configure-rule-schedule.md
index 7e3648d0028..3b7f425b515 100644
--- a/explore-analyze/alerting/esql/rules/configure-rule-schedule.md
+++ b/explore-analyze/alerting/esql/rules/configure-rule-schedule.md
@@ -1,7 +1,7 @@
---
navigation_title: Schedule and lookback
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/configure-rule-severity.md b/explore-analyze/alerting/esql/rules/configure-rule-severity.md
index 8d260c71bcd..4cbaa2ea1af 100644
--- a/explore-analyze/alerting/esql/rules/configure-rule-severity.md
+++ b/explore-analyze/alerting/esql/rules/configure-rule-severity.md
@@ -1,7 +1,7 @@
---
navigation_title: Severity
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/create-a-rule.md b/explore-analyze/alerting/esql/rules/create-a-rule.md
index 33bc3fa8dc5..f6e19d818bc 100644
--- a/explore-analyze/alerting/esql/rules/create-a-rule.md
+++ b/explore-analyze/alerting/esql/rules/create-a-rule.md
@@ -1,7 +1,7 @@
---
navigation_title: Create a rule
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/create-esql-rule.md b/explore-analyze/alerting/esql/rules/create-esql-rule.md
index 07ba7a4abe1..2935bc1dbbd 100644
--- a/explore-analyze/alerting/esql/rules/create-esql-rule.md
+++ b/explore-analyze/alerting/esql/rules/create-esql-rule.md
@@ -1,7 +1,7 @@
---
navigation_title: Create an ES|QL rule
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/create-rule-from-discover.md b/explore-analyze/alerting/esql/rules/create-rule-from-discover.md
index 0dafd362eef..97a7aaab4b0 100644
--- a/explore-analyze/alerting/esql/rules/create-rule-from-discover.md
+++ b/explore-analyze/alerting/esql/rules/create-rule-from-discover.md
@@ -1,7 +1,7 @@
---
navigation_title: Create from Discover
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/create-rules-action-policies-agent-builder.md b/explore-analyze/alerting/esql/rules/create-rules-action-policies-agent-builder.md
index f51429b51d1..06a8cf71f4e 100644
--- a/explore-analyze/alerting/esql/rules/create-rules-action-policies-agent-builder.md
+++ b/explore-analyze/alerting/esql/rules/create-rules-action-policies-agent-builder.md
@@ -1,7 +1,7 @@
---
navigation_title: Create rules using Agent Builder
applies_to:
- stack: experimental 9.5+
+ stack: experimental 9.6+
serverless: experimental
products:
- id: kibana
@@ -18,7 +18,7 @@ Before you start, make sure you have the following:
- **The required subscription** - {{agent-builder}} requires the appropriate {{stack}} [subscription](https://www.elastic.co/pricing) or {{serverless-short}} [project feature tier](/deploy-manage/deploy/elastic-cloud/project-settings.md#project-features-add-ons).
- **The `agentBuilder:experimentalFeatures` advanced setting turned on** - Go to the **Advanced Settings** menu using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md), and turn on `agentBuilder:experimentalFeatures`.
-- {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.6+` **The `alerting:v2:experimentalFeatures` advanced setting turned on** - The setting is off by default and applies only to the space where you turn it on. To turn it on, refer to [Try experimental features in a space](../setup.md#alerting-setup-experimental-features).
+- **The `alerting:v2:experimentalFeatures` advanced setting turned on** - The setting is off by default and applies only to the space where you turn it on. To turn it on, refer to [Try experimental features in a space](../setup.md#alerting-setup-experimental-features).
- **The required privileges** - Your role needs the [privileges to use {{agent-builder}} and save rules and action policies](../manage/configure-access.md#alerting-agent-builder-privileges).
## Propose and save a rule [ai-agent-rule-proposal]
@@ -66,8 +66,8 @@ Action policies invoke workflows for alerts only. If you ask the agent to set up
- **Workflows** - Workflows are the delivery mechanism. They define what happens when {{alerting-v2-system}} determines that a notification should be sent, such as posting to Slack, emailing a team, triggering PagerDuty, and so on.
- **Action Policies** - Action policies are the gating mechanism. {{kib}} evaluates them against the rule's alerts and invokes the workflow for the alerts they apply to. When you create an action policy with a rule, the policy applies to that rule's alerts.
- * {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.6+` The agent links the policy to the rule with a [routing tag](../action-policies/create-configure-action-policy.md#routing-tags). If the rule already has a routing tag that no other rule uses, the agent can reuse it. Otherwise, the agent adds a `notify-` routing tag to the rule and the policy, in lowercase with hyphens (for example, `notify-high-cpu-prod`). The policy also applies to alerts from any other rule with that routing tag. If the agent adds a routing tag to a rule you already saved, save the rule again so the tag takes effect.
- * {applies_to}`stack: removed 9.6+, experimental =9.5` {applies_to}`serverless: unavailable` The action policy references the rule by ID.
+
+ The agent links the policy to the rule with a [routing tag](../action-policies/create-configure-action-policy.md#routing-tags). If the rule already has a routing tag that no other rule uses, the agent can reuse it. Otherwise, the agent adds a `notify-` routing tag to the rule and the policy, in lowercase with hyphens (for example, `notify-high-cpu-prod`). The policy also applies to alerts from any other rule with that routing tag. If the agent adds a routing tag to a rule you already saved, save the rule again so the tag takes effect.
Both objects are proposed as inline attachments and must be explicitly saved before they take effect.
@@ -79,11 +79,6 @@ The three objects have a dependency chain that determines the order in which the
2. **Workflow** - The action policy references the workflow as a destination. The reference must resolve to a persisted workflow.
3. **Action policy** - Can only be saved after both its rule and workflow dependencies exist.
-:::{note}
-:applies_to: {"stack": "removed 9.6+, experimental =9.5", "serverless": "unavailable"}
-Action policies saved or edited through {{agent-builder}} also receive the `agent-builder-assisted` tag automatically, with the same behavior: user-editable and re-applied on subsequent agent edits.
-:::
-
## Related pages
- [{{agent-builder}}](/explore-analyze/ai-features/elastic-agent-builder.md): Learn how the {{agent-builder}} platform works, including agents, skills, and tools.
diff --git a/explore-analyze/alerting/esql/rules/esql-first-rule-query.md b/explore-analyze/alerting/esql/rules/esql-first-rule-query.md
index a721c1c5aac..e90339288fa 100644
--- a/explore-analyze/alerting/esql/rules/esql-first-rule-query.md
+++ b/explore-analyze/alerting/esql/rules/esql-first-rule-query.md
@@ -1,7 +1,7 @@
---
navigation_title: Your first rule query
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/esql-no-data-detection.md b/explore-analyze/alerting/esql/rules/esql-no-data-detection.md
index 51dfc558c14..ddf8239db56 100644
--- a/explore-analyze/alerting/esql/rules/esql-no-data-detection.md
+++ b/explore-analyze/alerting/esql/rules/esql-no-data-detection.md
@@ -1,7 +1,7 @@
---
navigation_title: No-data detection
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -28,10 +28,7 @@ FROM metrics-*
Every row returned is a host that has gone silent. The query result itself drives the alert. A separate alert condition isn't needed.
:::{note}
-This pattern opens an alert for a silent source. To control what the rule does with an alert that already exists when its data stops, refer to [No-data handling](configure-no-data-handling.md). When that setting applies depends on your version:
-
-* {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` The rule checks each group. If a group with an alert stops reporting, the rule applies **No data behavior** to that alert, even when other groups keep reporting. It never opens an alert for a group that hasn't breached.
-* {applies_to}`stack: experimental =9.5` The rule applies the setting only when the entire base query returns zero rows, for example when an index is completely empty.
+This pattern opens an alert for a silent source. To control what the rule does with an alert that already exists when its data stops, refer to [No-data handling](configure-no-data-handling.md). That setting applies to each group. If a group with an alert stops reporting, the rule applies **No data behavior** to that alert, even when other groups keep reporting. It never opens an alert for a group that hasn't breached.
:::
## Related pages
diff --git a/explore-analyze/alerting/esql/rules/esql-persistent-breach.md b/explore-analyze/alerting/esql/rules/esql-persistent-breach.md
index f6d5c16a50e..ca881bbf388 100644
--- a/explore-analyze/alerting/esql/rules/esql-persistent-breach.md
+++ b/explore-analyze/alerting/esql/rules/esql-persistent-breach.md
@@ -1,7 +1,7 @@
---
navigation_title: Persistent breach detection
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/esql-query-patterns.md b/explore-analyze/alerting/esql/rules/esql-query-patterns.md
index 1e2ec13a3aa..b646d2b9518 100644
--- a/explore-analyze/alerting/esql/rules/esql-query-patterns.md
+++ b/explore-analyze/alerting/esql/rules/esql-query-patterns.md
@@ -1,7 +1,7 @@
---
navigation_title: ES|QL query patterns
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/esql-slo-burn-rate.md b/explore-analyze/alerting/esql/rules/esql-slo-burn-rate.md
index f8d8ab8ce1c..fada1096907 100644
--- a/explore-analyze/alerting/esql/rules/esql-slo-burn-rate.md
+++ b/explore-analyze/alerting/esql/rules/esql-slo-burn-rate.md
@@ -1,7 +1,7 @@
---
navigation_title: SLO burn rate
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/esql-threshold-queries.md b/explore-analyze/alerting/esql/rules/esql-threshold-queries.md
index 69896f6603d..48cb389af8e 100644
--- a/explore-analyze/alerting/esql/rules/esql-threshold-queries.md
+++ b/explore-analyze/alerting/esql/rules/esql-threshold-queries.md
@@ -1,7 +1,7 @@
---
navigation_title: Threshold queries
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/review-rule-execution-history.md b/explore-analyze/alerting/esql/rules/review-rule-execution-history.md
index 32c31637f7f..9737770c3bf 100644
--- a/explore-analyze/alerting/esql/rules/review-rule-execution-history.md
+++ b/explore-analyze/alerting/esql/rules/review-rule-execution-history.md
@@ -1,7 +1,7 @@
---
navigation_title: Review rule execution history
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/rule-event-field-reference.md b/explore-analyze/alerting/esql/rules/rule-event-field-reference.md
index c982b81e65a..04572fca514 100644
--- a/explore-analyze/alerting/esql/rules/rule-event-field-reference.md
+++ b/explore-analyze/alerting/esql/rules/rule-event-field-reference.md
@@ -1,7 +1,7 @@
---
navigation_title: Rule events
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/use-rule-builder.md b/explore-analyze/alerting/esql/rules/use-rule-builder.md
index cd72058f31f..72cf4219f97 100644
--- a/explore-analyze/alerting/esql/rules/use-rule-builder.md
+++ b/explore-analyze/alerting/esql/rules/use-rule-builder.md
@@ -1,7 +1,7 @@
---
navigation_title: Create rules using the rule builder
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/view-manage-rules.md b/explore-analyze/alerting/esql/rules/view-manage-rules.md
index c8ad99cc16e..9d98369f207 100644
--- a/explore-analyze/alerting/esql/rules/view-manage-rules.md
+++ b/explore-analyze/alerting/esql/rules/view-manage-rules.md
@@ -1,7 +1,7 @@
---
navigation_title: View and manage rules
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
diff --git a/explore-analyze/alerting/esql/rules/yaml-rule-schema-reference.md b/explore-analyze/alerting/esql/rules/yaml-rule-schema-reference.md
index 3c07724a5a7..ad16af6ce3b 100644
--- a/explore-analyze/alerting/esql/rules/yaml-rule-schema-reference.md
+++ b/explore-analyze/alerting/esql/rules/yaml-rule-schema-reference.md
@@ -1,7 +1,7 @@
---
navigation_title: YAML rule schema reference
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -16,24 +16,17 @@ description: "YAML rule definitions support fields for detection mode, schedule,
These fields are required on every rule.
-{applies_to}`stack: experimental =9.5` The value of `query.format` determines which additional query fields are required.
-
| Field | Type | Accepted values | Description |
|---|---|---|---|
| `kind` | string | `alert` or `signal` | Whether the rule tracks ongoing alerts (`alert`) or records point-in-time observations (`signal`). Set when the rule is created and can't be modified when editing the rule. |
| `metadata.name` | string | Any string | The name of the rule. Max 256 characters. |
| `schedule.every` | duration | Any duration string | How often the rule runs. For example: `5s`, `1m`, `5m`. Minimum interval applies. |
-| `query.base` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | ES\|QL string | Any ES\|QL query | The query that selects the data the rule evaluates. |
-| `query.format` {applies_to}`stack: experimental =9.5` | string | `composed` or `standalone` | The query structure the rule uses. `standalone` means each condition (breach, recovery, no-data) is a separate, self-contained ES\|QL query. `composed` means you write one base query and each condition is a pipe segment appended to it. The UI always creates `standalone` rules. |
+| `query.base` | ES\|QL string | Any ES\|QL query | The query that selects the data the rule evaluates. |
-{applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` Rules with `kind: alert` also require the `recovery` and `no_data` objects. The rule APIs reject an alert rule that omits either one. If you omit them in the YAML editor of the rule form, {{kib}} fills in `strategy: no_breach` for `recovery` and `strategy: ignore` for `no_data`.
+Rules with `kind: alert` also require the `recovery` and `no_data` objects. The rule APIs reject an alert rule that omits either one. If you omit them in the YAML editor of the rule form, {{kib}} fills in `strategy: no_breach` for `recovery` and `strategy: ignore` for `no_data`.
## Query fields [query-fields]
-::::{applies-switch}
-
-:::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
Every rule has one base query that selects the data to evaluate. To match only some rows, add a breach segment. Without one, every row that `query.base` returns is a match.
| Field | Type | Description |
@@ -45,34 +38,6 @@ Several settings depend on the breach segment:
- To use the `condition` recovery strategy, set `query.breach`. Refer to [Recovery strategy](#recovery-strategy).
- To use a no-data strategy other than `ignore`, set `query.breach` or `no_data.query`. Refer to [No-data strategy](#no-data-strategy).
-:::
-
-:::{applies-item} stack: experimental =9.5
-
-In 9.5, `query.format` selects one of two query structures.
-
-**Fields for `query.format: composed`**
-
-Use `composed` when breach, recovery, and no-data conditions all start from the same data shape. Define that shape once in the base query and each condition adds only what differs.
-
-| Field | Type | Description |
-|---|---|---|
-| `query.base` | ES\|QL string | Base query that runs on every evaluation. Time filters are applied automatically using the lookback window. Required. |
-| `query.breach.segment` | ES\|QL segment string | ES\|QL segment appended to the base query for breach detection. Written as a pipe command, for example `\| WHERE count > 5`. Required. |
-| `query.recovery.segment` | ES\|QL segment string | ES\|QL segment appended to the base query for recovery detection. Required when `recovery_strategy` is `query`. |
-
-**Fields for `query.format: standalone`**
-
-Use `standalone` when conditions need full independence. Each query can target different indices, apply different filters, or return a completely different shape.
-
-| Field | Type | Description |
-|---|---|---|
-| `query.breach.query` | Full ES\|QL string | Full ES\|QL query for breach detection. Required. |
-| `query.recovery.query` | Full ES\|QL string | Full ES\|QL query for recovery detection. Required when `recovery_strategy` is `query`. |
-| `query.no_data.query` | Full ES\|QL string | Full ES\|QL query that detects presence of data. Required when `no_data_strategy` is not `none`. Only supported on `standalone` format. |
-:::
-
-::::
## Metadata fields
@@ -81,9 +46,8 @@ These optional fields add descriptive information to a rule for identification a
| Field | Type | Accepted values | Description |
|---|---|---|---|
| `metadata.description` | string | Any string | Optional description of what the rule monitors. Max 1,024 characters. |
-| `metadata.owner` {applies_to}`stack: experimental =9.5` | string | Any string | Team or person responsible for the rule. Max 256 characters. |
| `metadata.tags` | array of strings | Array of strings | Labels for filtering and organization. Max 20 tags, each max 128 characters. |
-| `metadata.routing_tags` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | array of strings | Array of strings | Tags that link the rule's alerts to action policies. An action policy applies when it has at least one of these tags. Only valid when `kind: alert`. Max 20 tags, each max 128 characters. To learn more, refer to [Add routing tags to a rule](../action-policies/create-configure-action-policy.md#add-routing-tags). |
+| `metadata.routing_tags` | array of strings | Array of strings | Tags that link the rule's alerts to action policies. An action policy applies when it has at least one of these tags. Only valid when `kind: alert`. Max 20 tags, each max 128 characters. To learn more, refer to [Add routing tags to a rule](../action-policies/create-configure-action-policy.md#add-routing-tags). |
## Schedule fields
@@ -96,10 +60,6 @@ These fields control how far back each evaluation looks and which timestamp fiel
## Recovery strategy [recovery-strategy]
-:::::{applies-switch}
-
-::::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
The `recovery` object controls how {{kib}} detects that an alert has recovered. It's required when `kind: alert`, and `strategy` selects the behavior.
| Field | Type | Accepted values | Description |
@@ -113,31 +73,11 @@ The `condition` strategy requires `query.breach`. Without a breach segment, ever
:::{note}
Rules with `kind: signal` can't set `recovery`. A rule with `strategy: manual` can't set `state_transition.recovering`, because the recovery delay has no effect when alerts never recover on their own.
:::
-::::
-
-::::{applies-item} stack: experimental =9.5
-
-The `recovery_strategy` field is optional. When omitted, the rule emits no recovery events and active alerts don't close automatically.
-
-| Field | Type | Accepted values | Description |
-|---|---|---|---|
-| `recovery_strategy` | string | `no_breach`, `query`, or `none` | How recovery is detected.
-`no_breach`: Recovers an alert when its active group no longer appears in the breach results.
- `query`: Evaluates a separate recovery query defined in `query.recovery.segment` (composed) or `query.recovery.query` (standalone)
- `none`: Turns off recovery. |
-
-:::{note}
-Rules with `kind: signal` must omit `recovery_strategy` or set it to `none`. Any other value fails validation.
-:::
-::::
-
-:::::
## State transition fields [state-transition-fields]
Only valid when `kind: alert`. Controls how many consecutive detections are required before an alert becomes active or recovers.
-::::{applies-switch}
-
-:::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
State transition settings are nested objects. `state_transition.pending` delays when an alert opens, and `state_transition.recovering` delays when an alert closes. In each object, set `count`, `timeframe`, or both.
| Field | Type | Accepted values | Description |
@@ -158,21 +98,6 @@ state_transition:
recovering:
count: 1
```
-:::
-
-:::{applies-item} stack: experimental =9.5
-
-| Field | Type | Accepted values | Description |
-|---|---|---|---|
-| `state_transition.pending_operator` | string | `AND` or `OR` | Whether both the count and timeframe must be met (`AND`) or either one (`OR`) before becoming active. |
-| `state_transition.pending_count` | integer | Integer, 0–1000 | Number of consecutive breaches required before the alert becomes active. Set to `0` to skip the pending phase and transition directly to active on the first breach. |
-| `state_transition.pending_timeframe` | duration | Any duration string | How long the condition must remain continuously breached before the alert becomes active. For example: `5m`. |
-| `state_transition.recovering_operator` | string | `AND` or `OR` | Whether both the count and timeframe must be met (`AND`) or either one (`OR`) before recovering. |
-| `state_transition.recovering_count` | integer | Integer, 0–1000 | Number of consecutive clear evaluations required before the alert recovers. Set to `0` to skip the recovering phase and transition directly to inactive on recovery. |
-| `state_transition.recovering_timeframe` | duration | Any duration string | How long the condition must remain continuously non-breaching before the alert recovers. For example: `5m`. |
-:::
-
-::::
## Grouping fields
@@ -186,10 +111,6 @@ Use grouping to split a rule's detections into independent series, one per uniqu
When a data source goes silent, a quiet source and a healthy one can look the same to a rule. The no-data setting controls what the rule does with an alert when its group has no data.
-:::::{applies-switch}
-
-::::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
The `no_data` object is required when `kind: alert`, and `strategy` selects the behavior.
| Field | Type | Accepted values | Description |
@@ -202,44 +123,23 @@ A strategy other than `ignore` requires `query.breach` or `no_data.query`. That
:::{note}
Rules with `kind: signal` can't set `no_data`.
:::
-::::
-
-::::{applies-item} stack: experimental =9.5
-
-Use `no_data_strategy` to control what the rule does when an evaluation returns no results.
-
-| Field | Type | Accepted values | Description |
-|---|---|---|---|
-| `no_data_strategy` | string | `emit`, `last_known_status`, `recover`, or `none` | Optional. What happens when the rule evaluates and returns no results. `emit` records a no-data event. `last_known_status` holds the last known status. `recover` forces recovery. `none` disables no-data detection. |
-
-:::{note}
-No-data detection is only supported with `query.format: standalone`. Setting `no_data_strategy` to any active value on a `composed` rule has no effect because `query.no_data.query` can only be defined on a standalone query. Rules with `kind: signal` must omit `no_data_strategy` or set it to `none`.
-:::
-::::
-
-:::::
## Artifact fields
Artifacts let you attach reference material directly to a rule, such as a runbook or a linked dashboard. {{kib}} stores the artifact with the rule and displays it on the rule details page, so responders have context when an alert fires.
-The `artifacts` array is optional and accepts up to 100 entries. Every artifact needs `id` and `type`. Use `data` or `value` for the content, as shown in the following table.
+The `artifacts` array is optional and accepts up to 100 entries. Every artifact needs `id`, `type`, and `data`, as shown in the following table.
| Field | Type | Accepted values | Description |
|---|---|---|---|
| `artifacts[].id` | string | Any string | Artifact identifier. Required. Max 256 characters. |
| `artifacts[].type` | string | Any string | Use `runbook` or `dashboard`. Other strings are allowed. Max 128 characters. |
-| `artifacts[].data` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | object | Type-specific object | Required. The artifact's content. Max 32 fields. |
-| `artifacts[].data.content` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | string | Non-empty string | The Markdown body of a runbook. {{kib}} displays it on the **Runbook** tab of the rule details page. Required when `type` is `runbook`. Max 50,000 characters. |
-| `artifacts[].data.dashboard_id` {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` | string | Non-empty string | ID of the dashboard to link. Required when `type` is `dashboard`. Max 1,024 characters. |
-| `artifacts[].value` {applies_to}`stack: experimental =9.5` | string | Any string | Required. Runbook Markdown (max 50,000 characters) or a dashboard ID (max 1,024 characters). |
+| `artifacts[].data` | object | Type-specific object | Required. The artifact's content. Max 32 fields. |
+| `artifacts[].data.content` | string | Non-empty string | The Markdown body of a runbook. {{kib}} displays it on the **Runbook** tab of the rule details page. Required when `type` is `runbook`. Max 50,000 characters. |
+| `artifacts[].data.dashboard_id` | string | Non-empty string | ID of the dashboard to link. Required when `type` is `dashboard`. Max 1,024 characters. |
The following example attaches a runbook and a dashboard to the same rule.
-::::{applies-switch}
-
-:::{applies-item} { serverless: ga, stack: ga 9.6+ }
-
```yaml
artifacts:
- id: checkout-runbook
@@ -257,28 +157,6 @@ artifacts:
2. The runbook Markdown goes in `data.content`.
3. The dashboard ID goes in `data.dashboard_id`.
-If {{kib}} loads a rule that still uses `value`, it converts that field to `data`. Write new YAML with `data`.
-:::
-
-:::{applies-item} stack: experimental =9.5
-
-```yaml
-artifacts:
- - id: checkout-runbook
- type: runbook
- value: | <1>
- Fires when checkout error rate exceeds 10%.
- - id: checkout-errors-dashboard
- type: dashboard
- value: "8ac12f90-3d2b-11ef-9a4e-0242ac120002" <2>
-```
-
-1. The runbook Markdown goes in `value`.
-2. The dashboard ID goes in `value`.
-:::
-
-::::
-
## Duration format [duration-format]
All duration fields accept the following units:
diff --git a/explore-analyze/alerting/esql/setup.md b/explore-analyze/alerting/esql/setup.md
index 5630d4dd711..7ca3af8d881 100644
--- a/explore-analyze/alerting/esql/setup.md
+++ b/explore-analyze/alerting/esql/setup.md
@@ -1,80 +1,56 @@
---
navigation_title: Set up
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
- id: cloud-serverless
-description: "License, connector, data, and space requirements, plus how to turn the system on and off."
+description: "License, connector, data, and space requirements, plus how to turn on optional features or opt out of the system."
---
# Set up {{alerting-v2-system}} [setup]
-Check the requirements for {{alerting-v2-system}}, turn it on or off for all spaces, and turn on optional features in the spaces where you want them.
+{{alerting-v2-system-cap}} is on by default. Check that you have what you need to create rules, then turn on any optional features you want.
-## Before you use the system [alerting-setup-requirements]
+:::{note}
+If you tried {{alerting-v2-system}} while it was experimental in {{stack}} 9.5, upgrade to 9.6 or later. The system changed a lot before it became generally available, and these docs cover only the generally available version.
+:::
-You'll need the following to create rules and send notifications.
+## Before you begin [alerting-setup-requirements]
-- **Data in Elasticsearch**: Rules can only detect conditions in data that already exists. Make sure the indices or data streams your rules will query are populated before creating rules. Refer to [Ingest your data](/manage-data/ingest.md) for options.
-- **A space selected**: Rules, [action policies](action-policies/about-action-policies.md), and the privileges that control them are all space-scoped. Decide which space you'll work in before setting things up. Refer to [Manage spaces](/deploy-manage/manage-spaces.md) to create or switch spaces.
-- **Connectors configured** (required for notifications): [Workflows](workflows-alerting.md) send notifications and require at least one [connector](/deploy-manage/manage-connectors.md), for example, Slack, email, or PagerDuty. [Action policies](action-policies/about-action-policies.md) invoke those workflows.
-- **Enterprise license** (Stack deployments only, required for notifications): Workflows-based notifications require an Enterprise license. Refer to the subscription page for [Elastic Cloud](https://www.elastic.co/subscriptions/cloud) and [Elastic Stack/self-managed](https://www.elastic.co/subscriptions) for the breakdown of available features and their associated subscription tiers.
+- **Data to query**: Rules can only find conditions in data that's already in {{es}}. [Ingest your data](/manage-data/ingest.md) before you create rules.
+- **A space to work in**: Rules, [action policies](action-policies/about-action-policies.md), and the privileges that control them belong to a single space. [Create or switch spaces](/deploy-manage/manage-spaces.md) if you need to.
+- **A connector, if you want notifications**: [Workflows](workflows-alerting.md) send notifications through [connectors](/deploy-manage/manage-connectors.md), such as Slack, email, or PagerDuty.
+- **An Enterprise license, if you want notifications on {{stack}}**: Compare subscriptions for [{{ecloud}}](https://www.elastic.co/subscriptions/cloud) and [self-managed](https://www.elastic.co/subscriptions) deployments.
-## Turn on the system [alerting-setup-turn-on]
+## Adjust {{alerting-v2-system}} settings [alerting-setup-settings]
-{{alerting-v2-system-cap}} is controlled by the [`alerting:v2:enabled`](kibana://reference/advanced-settings.md#alerting-v2-enabled) advanced setting in {{kib}}. This is a global setting, so turning it on makes {{alerting-v2-system}} available in every space, even though the rules and action policies you create in it are space-scoped.
+Three advanced settings change how {{alerting-v2-system}} works. A space setting applies only to the space where you change it. A global setting applies to every space.
-The setting's default state depends on your version:
+| Setting | Scope | Default | Use it to |
+|---|---|---|---|
+| **Universal Alerting: Experimental Features** (`alerting:v2:experimentalFeatures`) | Space | Off | [Try experimental features](#alerting-setup-experimental-features) |
+| **Classic Alerting: Show Classic Alerts table** (`alerting:v1:showV1ObservabilityAlertsTable`) | Space | Off | [Keep the {{observability}} Alerts page](#alerting-setup-v1-alerts-page) |
+| **Universal Alerting** (`alerting:v2:enabled`) | Global | On | [Opt out of {{alerting-v2-system}}](#alerting-setup-turn-off) |
-- {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` The setting is on by default. If you turned the setting off, it stays off, even after an upgrade.
-- {applies_to}`stack: experimental =9.5` The setting is off by default.
-
-To turn on the setting:
-
-1. Go to the **Advanced Settings** page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
-2. Select the **Global Settings** tab, turn on `alerting:v2:enabled`, save the change, then refresh the page.
-3. Confirm that {{alerting-v2-system}} is accessible in your space. Find **Rules** using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md), or go to:
-
- - {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` **Alerting** → **Rules** in the {{observability}} navigation menu
- - {applies_to}`stack: experimental =9.5` **Stack Management** → **Alerting V2 Preview** → **Rules**
-
-## Turn off the system [alerting-setup-turn-off]
-
-To turn off {{alerting-v2-system}}, go to the **Advanced Settings** page, select the **Global Settings** tab, and turn off `alerting:v2:enabled`.
-
-Turning off the setting hides the {{alerting-v2-system}} UI and turns off its APIs, but it doesn't delete any data. {{kib}} keeps your rules and action policies as saved objects, along with existing documents in `.rule-events` and `.alert-actions`. Turning the setting back on restores the UI and APIs.
-
-### Stop rules and action policies from running [alerting-setup-stop-execution]
-
-Turning off the setting doesn't stop rules and action policies from running. To stop them, use the option for your deployment:
-
-- {applies_to}`serverless: ga` [Contact Elastic support](/troubleshoot/index.md#contact-us).
-- {applies_to}`stack: ga 9.6+, experimental =9.5` Set `xpack.alerting_v2.enabled: false` in [`kibana.yml`](/deploy-manage/stack-settings.md), then restart {{kib}}.
-
-## Try experimental features in a space [alerting-setup-experimental-features]
+### Try experimental features in a space [alerting-setup-experimental-features]
```yaml {applies_to}
serverless: experimental
stack: experimental 9.6+
```
-To try features of {{alerting-v2-system}} that are still experimental, turn on the **Universal Alerting: Experimental Features** advanced setting (`alerting:v2:experimentalFeatures`). The setting is off by default and applies only to the space where you turn it on.
+Experimental features are new {{alerting-v2-system}} capabilities that are still in development. They can change or be removed in a future release, so avoid relying on them in production.
-When the setting is on, you can:
+To turn them on:
-- Detect multi-step alert patterns by chaining rules into a sequence. On the **Rules** page, select **Build a sequence (Experimental)**.
-- Create rules and action policies by describing them to {{agent-builder}} in natural language. Select **Create rule** → **Create with agent (Experimental)** on the **Rules** page, or **Create policy** → **Create with agent (Experimental)** on the **Action Policies** page. {{agent-builder}} has [its own requirements](rules/create-rules-action-policies-agent-builder.md#create-ai-agent-requirements).
-
-To turn on experimental features:
-
-1. Switch to the space where you want to use the features.
+1. Switch to the space where you want the features.
2. Go to the **Advanced Settings** page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
-3. Select the **Space Settings** tab, then turn on **Universal Alerting: Experimental Features**.
+3. On the **Space Settings** tab, turn on **Universal Alerting: Experimental Features**.
4. Select **Save changes**, then reload {{kib}}.
-## Keep the Observability alerts page for {{alerting-v1-system}} [alerting-setup-v1-alerts-page]
+### Keep the {{observability}} Alerts page for {{alerting-v1-system}} [alerting-setup-v1-alerts-page]
```yaml {applies_to}
serverless:
@@ -82,20 +58,30 @@ serverless:
stack: ga 9.6+
```
-When {{alerting-v2-system}} is on, an **Alerting** menu replaces the Observability **Alerts** link. Its **Alerts** page lists alerts from both systems, even if you keep the old page.
-
-To keep using the Observability alerts page that lists only alerts from {{alerting-v1-system}} rules, turn on the **Classic Alerting: Show Classic Alerts table** advanced setting (`alerting:v1:showV1ObservabilityAlertsTable`). The page then appears as **Alerts (Classic)** in the **Alerting** menu and in global search results. The setting is off by default and applies only to the space where you turn it on.
+With {{alerting-v2-system}} on, a new **Alerts** page that shows alerts from both systems replaces the {{observability}} **Alerts** page, which shows only {{alerting-v1-system}} alerts. You can find the new page in the **Alerting** menu. To keep the old page as well, turn on the **Classic Alerting: Show Classic Alerts table** setting. The old page then appears as **Alerts (Classic)** in the **Alerting** menu.
To show the **Alerts (Classic)** page:
1. Switch to the space where you want the page.
2. Go to the **Advanced Settings** page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
-3. Select the **Space Settings** tab, then turn on **Classic Alerting: Show Classic Alerts table**.
+3. On the **Space Settings** tab, turn on **Classic Alerting: Show Classic Alerts table**.
4. Select **Save changes**, then reload {{kib}}.
-## Next steps [alerting-setup-next-steps]
+### Opt out of {{alerting-v2-system}} [alerting-setup-turn-off]
+
+To turn off {{alerting-v2-system}} in every space:
+
+1. Go to the **Advanced Settings** page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
+2. On the **Global Settings** tab, turn off [**Universal Alerting**](kibana://reference/advanced-settings.md#alerting-v2-enabled).
+3. Select **Save changes**, then reload {{kib}}.
+
+This hides the UI and turns off the APIs. Your rules, action policies, and alert history stay in place, and the setting stays off after upgrades.
+
+Rules and action policies keep running after you turn off the setting. To stop them:
-After you meet the requirements and the system is on:
+- {applies_to}`serverless: ga` [Contact Elastic support](/troubleshoot/index.md#contact-us).
+- {applies_to}`stack: ga 9.6+` Set `xpack.alerting_v2.enabled: false` in [`kibana.yml`](/deploy-manage/stack-settings.md), then restart {{kib}}.
+
+## Next steps [alerting-setup-next-steps]
-- [Configure access](manage/configure-access.md) to create or update a role with access to the {{alerting-v2-system}} features and the data streams they write to.
-- [Create your first rule](get-started/create-your-first-rule.md) to load sample data, write a detection query, and observe the alert lifecycle.
+[Create your first rule](get-started/create-your-first-rule.md) to try {{alerting-v2-system}} with sample data.
diff --git a/explore-analyze/alerting/esql/system-overview.md b/explore-analyze/alerting/esql/system-overview.md
index 1c7c9555843..f8c3b2fcec3 100644
--- a/explore-analyze/alerting/esql/system-overview.md
+++ b/explore-analyze/alerting/esql/system-overview.md
@@ -1,7 +1,7 @@
---
navigation_title: "{{alerting-v2-system-cap}}"
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -13,13 +13,12 @@ description: Kibana Universal Alerting writes each match as a rule event, then e
Use {{alerting-v2-system}} to detect conditions in your {{es}} data with {{esql}} rules. You can track each problem as an alert from first detection through recovery and route its notifications through reusable action policies, or record matches for later analysis without sending notifications.
+To open {{alerting-v2-system}}, go to **Alerting** in the {{observability}} navigation menu.
+
:::{note}
Looking for {{alerting-v1-system}}? Refer to the [{{alerting-v1-system-cap}} overview](/explore-analyze/alerting/alerts.md) instead. The two systems are separate, so APIs and instructions for one don't apply to the other.
-:::
-:::{admonition} Where to find {{alerting-v2-system}} pages in each version
-- {applies_to}`serverless: ga` {applies_to}`stack: ga 9.6+` Go to **Alerting** in the {{observability}} navigation menu.
-- {applies_to}`stack: experimental =9.5` Go to **Stack Management** → **Alerting V2 Preview**. The UI also calls an alert an **alert episode**. For example, the **Notify per** option for one notification per alert is **Episode** instead of **Alert**.
+If you tried {{alerting-v2-system}} while it was experimental in {{stack}} 9.5, upgrade to 9.6 or later to use the generally available version. The system changed significantly between 9.5 and 9.6. This documentation covers only the generally available version.
:::
## The building blocks
@@ -46,7 +45,7 @@ For a step-by-step walkthrough of what happens after a rule runs, refer to [How
## Get started or go deeper [system-overview-next-steps]
- [Get started](get-started.md): Learn how the system works and its key terms, then create your first rule in a hands-on tutorial.
-- [Set up {{alerting-v2-system}}](setup.md): Check the requirements, then turn the system on or off.
+- [Set up {{alerting-v2-system}}](setup.md): Check the requirements and turn on optional features.
- [Manage](manage.md): Give your team the role privileges it needs, and manage the API keys that authorize rules, action policies, and workflows.
- [Rules](rules.md): Define what to watch for in {{esql}}, and decide which creation path fits your use case.
- [Alerts](alerts.md): Learn how alerts track a problem from first detection through recovery, and how to triage them.
diff --git a/explore-analyze/alerting/esql/workflows-alerting.md b/explore-analyze/alerting/esql/workflows-alerting.md
index bf5835f62d4..087d2e2dbbf 100644
--- a/explore-analyze/alerting/esql/workflows-alerting.md
+++ b/explore-analyze/alerting/esql/workflows-alerting.md
@@ -1,7 +1,7 @@
---
navigation_title: Connect workflows
applies_to:
- stack: ga 9.6+, experimental =9.5
+ stack: ga 9.6+
serverless: ga
products:
- id: kibana
@@ -24,10 +24,10 @@ In {{alerting-v2-system}}, [workflows](../../workflows.md) define what happens i
```{applies_to}
serverless: preview
-stack: ga 9.6+, experimental =9.5
+stack: preview 9.6+
```
-Lifecycle triggers are [event-driven triggers](../../workflows/triggers/event-driven-triggers.md) that start a workflow immediately when a user [resolves, assigns, acknowledges, or snoozes](alerts/triage-alert-episodes.md) an alert, with no scheduling or gating. Each action emits a named trigger event, such as `alerting.actions.alertAssigned` (`alerting.episodeAssigned` in earlier versions).
+Lifecycle triggers are [event-driven triggers](../../workflows/triggers/event-driven-triggers.md) that start a workflow immediately when a user [resolves, assigns, acknowledges, or snoozes](alerts/triage-alert-episodes.md) an alert, with no scheduling or gating. Each action emits a named trigger event, such as `alerting.actions.alertAssigned`.
Lifecycle triggers don't fire on [automatic status changes](alerts.md#alert-episode-lifecycle), such as when an alert becomes active or recovers based on rule evaluations. To respond to those changes, use an action policy. For the full list of trigger IDs, refer to [Alert lifecycle triggers](../../workflows/triggers/event-driven-triggers.md#alert-episode-lifecycle-triggers-available).
diff --git a/explore-analyze/workflows/triggers.md b/explore-analyze/workflows/triggers.md
index a7d542e5259..8435ab80cf2 100644
--- a/explore-analyze/workflows/triggers.md
+++ b/explore-analyze/workflows/triggers.md
@@ -105,15 +105,15 @@ Event-driven triggers run workflows when a platform event occurs:
* {applies_to}`serverless: ga` {applies_to}`stack: ga 9.5+, preview =9.4` **`workflows.failed`** fires when another workflow's execution fails.
* {applies_to}`serverless: preview` {applies_to}`stack: preview 9.5+` **Cases triggers** fire when cases change. The family includes `cases.caseCreated`, `cases.caseUpdated`, `cases.caseStatusUpdated`, `cases.attachmentsAdded`, and `cases.commentsAdded`.
* {applies_to}`serverless: preview` {applies_to}`stack: preview 9.5+` **Entity store triggers** fire when an entity's asset criticality or risk score changes in the entity store. The family includes `entityStore.entityAssetCriticalityUpdated` and `entityStore.entityRiskScoreChanged`.
-* {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.5+` **Alert lifecycle triggers in {{alerting-v2-system}}** fire when a user takes a triage action on an alert, such as resolving, assigning, acknowledging, or snoozing it.
-* {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.5+` **Rule lifecycle triggers in {{alerting-v2-system}}** fire when someone creates, updates, deletes, enables, or disables a rule. The family includes `alerting.ruleCreated`, `alerting.ruleUpdated`, `alerting.ruleDeleted`, `alerting.ruleEnabled`, and `alerting.ruleDisabled`.
+* {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` **Alert lifecycle triggers in {{alerting-v2-system}}** fire when a user takes a triage action on an alert, such as resolving, assigning, acknowledging, or snoozing it.
+* {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` **Rule lifecycle triggers in {{alerting-v2-system}}** fire when someone creates, updates, deletes, enables, or disables a rule. The family includes `alerting.ruleCreated`, `alerting.ruleUpdated`, `alerting.ruleDeleted`, `alerting.ruleEnabled`, and `alerting.ruleDisabled`.
Use event-driven triggers for:
* Central error-handler workflows that react to failures across your automation
* Reacting to case lifecycle changes (case opened, status changed, attachments or comments added)
* Paging on-call, opening cases, or logging when a production workflow fails
-* {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.5+` Auditing rule management actions, syncing rule inventory with external systems, or notifying a channel when rules change in {{alerting-v2-system}}
+* {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` Auditing rule management actions, syncing rule inventory with external systems, or notifying a channel when rules change in {{alerting-v2-system}}
Event-driven trigger example:
@@ -135,8 +135,8 @@ Each trigger type provides different data to the workflow context through the `e
* `workflows.failed` provides metadata about the failed workflow, its execution, and the step that failed.
* Cases triggers provide `event.caseId`, `event.owner`, and event-specific fields (status changes carry `previousStatus` and `status`; attachment events carry IDs and type; comment events carry IDs).
* {applies_to}`serverless: preview` {applies_to}`stack: preview 9.5+` Entity store triggers provide `event.entityId`, `event.entityType`, and event-specific fields (asset criticality changes carry `criticalityLevel`; risk score changes carry `score`, `previousScore`, `delta`, and `direction`).
- * {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.5+` Alert lifecycle triggers in {{alerting-v2-system}} provide `event.alertId` (`event.episodeId` in earlier versions), `event.ruleId`, and `event.spaceId`.
- * {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.5+` Rule lifecycle triggers in {{alerting-v2-system}} provide `event.rule.ruleId` and `event.rule.spaceId`.
+ * {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` Alert lifecycle triggers in {{alerting-v2-system}} provide `event.alertId`, `event.ruleId`, and `event.spaceId`.
+ * {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` Rule lifecycle triggers in {{alerting-v2-system}} provide `event.rule.ruleId` and `event.rule.spaceId`.
Refer to [Event-driven triggers](/explore-analyze/workflows/triggers/event-driven-triggers.md) for the full payload shapes.
diff --git a/explore-analyze/workflows/triggers/event-driven-triggers.md b/explore-analyze/workflows/triggers/event-driven-triggers.md
index 02877b4e327..2a2ba60147c 100644
--- a/explore-analyze/workflows/triggers/event-driven-triggers.md
+++ b/explore-analyze/workflows/triggers/event-driven-triggers.md
@@ -20,8 +20,8 @@ Event-driven triggers let workflows react to events elsewhere in {{kib}}. The fo
- {applies_to}`serverless: ga` {applies_to}`stack: ga 9.5+, preview =9.4` **`workflows.failed`**: Fires when another workflow's execution fails.
- {applies_to}`serverless: preview` {applies_to}`stack: preview 9.5+` **Cases triggers**: Fire when cases change (created, updated, status changed, attachments added, comments added).
- {applies_to}`serverless: preview` {applies_to}`stack: preview 9.5+` **Entity store triggers**: Fire when an entity's asset criticality or risk score changes in the entity store.
-- {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.5+` **Alert lifecycle triggers in {{alerting-v2-system}}**: Fire when a user takes a triage action on an alert, such as resolving, assigning, acknowledging, or snoozing it.
-- {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.5+` **Rule lifecycle triggers in {{alerting-v2-system}}**: Fire when someone creates, updates, deletes, enables, or disables a rule.
+- {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` **Alert lifecycle triggers in {{alerting-v2-system}}**: Fire when a user takes a triage action on an alert, such as resolving, assigning, acknowledging, or snoozing it.
+- {applies_to}`serverless: preview` {applies_to}`stack: preview 9.6+` **Rule lifecycle triggers in {{alerting-v2-system}}**: Fire when someone creates, updates, deletes, enables, or disables a rule.
:::{include} ../_snippets/schema-location-legend.md
@@ -454,7 +454,7 @@ triggers:
```{applies_to}
serverless: preview
-stack: experimental 9.5+
+stack: preview 9.6+
```
:::{note}
@@ -467,21 +467,17 @@ Each trigger fires exactly once per event. To subscribe a workflow, add the trig
### Available triggers [alert-episode-lifecycle-triggers-available]
-:::{note}
-The trigger IDs changed after {{stack}} 9.5. If you upgrade, update workflows that use the earlier IDs, because they stop firing until you switch them to the matching current ID.
-:::
-
-| Trigger ID {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.6+` | Trigger ID {applies_to}`stack: experimental =9.5` | When it fires |
-|---|---|---|
-| `alerting.actions.alertActivated` | `alerting.episodeActivated` | A user unresolves an alert. |
-| `alerting.actions.alertDeactivated` | `alerting.episodeDeactivated` | A user resolves an alert. |
-| `alerting.actions.alertSnoozed` | `alerting.episodeSnoozed` | An alert is snoozed. |
-| `alerting.actions.alertUnsnoozed` | `alerting.episodeUnsnoozed` | An alert is unsnoozed. |
-| `alerting.actions.alertAcked` | `alerting.episodeAcked` | An alert is acknowledged. |
-| `alerting.actions.alertUnacked` | `alerting.episodeUnacked` | An alert acknowledgment is removed. |
-| `alerting.actions.alertAssigned` | `alerting.episodeAssigned` | An alert is assigned to a user. |
-| `alerting.actions.alertUnassigned` | `alerting.episodeUnassigned` | An alert assignment is removed. |
-| `alerting.actions.alertTagged` | `alerting.episodeTagged` | A tag is applied to an alert. |
+| Trigger ID | When it fires |
+|---|---|
+| `alerting.actions.alertActivated` | A user unresolves an alert. |
+| `alerting.actions.alertDeactivated` | A user resolves an alert. |
+| `alerting.actions.alertSnoozed` | An alert is snoozed. |
+| `alerting.actions.alertUnsnoozed` | An alert is unsnoozed. |
+| `alerting.actions.alertAcked` | An alert is acknowledged. |
+| `alerting.actions.alertUnacked` | An alert acknowledgment is removed. |
+| `alerting.actions.alertAssigned` | An alert is assigned to a user. |
+| `alerting.actions.alertUnassigned` | An alert assignment is removed. |
+| `alerting.actions.alertTagged` | A tag is applied to an alert. |
### Event payload [alert-episode-lifecycle-triggers-event]
@@ -489,8 +485,7 @@ All lifecycle triggers include these common fields in the event payload.
| `event.*` field | Contains |
|---|---|
-| `event.alertId` {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.6+` | Unique identifier of the alert. |
-| `event.episodeId` {applies_to}`stack: experimental =9.5` | Unique identifier of the alert. Replaced by `event.alertId` in later versions. |
+| `event.alertId` | Unique identifier of the alert. |
| `event.ruleId` | ID of the rule that produced the alert. |
| `event.spaceId` | ID of the {{kib}} space where the event occurred. |
@@ -510,7 +505,7 @@ Use these fields to write workflow conditions that scope the automation to speci
```{applies_to}
serverless: preview
-stack: experimental 9.5+
+stack: preview 9.6+
```
:::{note}
@@ -557,7 +552,7 @@ All rule lifecycle triggers share the same minimal payload.
|---|---|
| `event.rule.ruleId` | Unique identifier of the rule that was created, updated, deleted, enabled, or disabled. |
| `event.rule.spaceId` | ID of the {{kib}} space where the operation occurred. |
-| `event.rule.tags` {applies_to}`serverless: preview` {applies_to}`stack: experimental 9.6+` | Tags assigned to the rule. |
+| `event.rule.tags` | Tags assigned to the rule. |
Reference these fields with Liquid templating in workflow steps:
diff --git a/solutions/security/detect-and-alert.md b/solutions/security/detect-and-alert.md
index 4d9263b8b07..1d91227c4f5 100644
--- a/solutions/security/detect-and-alert.md
+++ b/solutions/security/detect-and-alert.md
@@ -19,7 +19,7 @@ products:
The detection engine also surfaces alerts from [{{elastic-defend}}'s endpoint protection](/solutions/security/manage-elastic-defend/endpoint-protection-rules.md) (malware, ransomware, memory threats, and malicious behavior) and [external alerts](https://www.elastic.co/docs/reference/security/prebuilt-rules/rules/promotions/external_alerts) from third-party tools like Suricata, giving you a unified view of threats across your security stack.
:::{note}
-:applies_to: {"serverless": "ga", "stack": "ga 9.6+, experimental =9.5"}
+:applies_to: {"serverless": "ga", "stack": "ga 9.6+"}
[{{alerting-v2-system-cap}}](/explore-analyze/alerting/esql/system-overview.md) is a separate alerting system that isn't tied to any specific solution. Its rules aren't the same as {{elastic-sec}} [{{esql}} rules](/solutions/security/detect-and-alert/esql.md). For threat detection, use {{elastic-sec}} detection rules. They include security-specific capabilities such as [exceptions](/solutions/security/detect-and-alert/rule-exceptions.md) and [alert suppression](/solutions/security/detect-and-alert/alert-suppression.md) that {{alerting-v2-system}} doesn't provide.
:::