diff --git a/deploy-manage/deploy/cloud-on-k8s/k8s-service-mesh-istio.md b/deploy-manage/deploy/cloud-on-k8s/k8s-service-mesh-istio.md
index 11bf6b42b5..9dbe2bfd81 100644
--- a/deploy-manage/deploy/cloud-on-k8s/k8s-service-mesh-istio.md
+++ b/deploy-manage/deploy/cloud-on-k8s/k8s-service-mesh-istio.md
@@ -15,7 +15,7 @@ The instructions in this section describe how to connect the operator and manage
These instructions have been tested with Istio 1.24.3. Older or newer versions of Istio might require additional configuration steps not documented here.
::::{warning}
-Some {{stack}} features such as [{{kib}} alerting and actions](/explore-analyze/alerting.md) rely on the {{es}} API keys feature which requires TLS to be enabled at the application level. If you want to use these features, you should not disable the self-signed certificate on the {{es}} resource and enable `PERMISSIVE` mode for the {{es}} service through a `DestinationRule` or `PeerAuthentication` resource. Strict mTLS mode is currently not compatible with {{stack}} features requiring TLS to be enabled for the {{es}} HTTP layer.
+Some {{stack}} features such as [{{kib}} alerting and actions](/explore-analyze/alerting-overview.md) rely on the {{es}} API keys feature which requires TLS to be enabled at the application level. If you want to use these features, you should not disable the self-signed certificate on the {{es}} resource and enable `PERMISSIVE` mode for the {{es}} service through a `DestinationRule` or `PeerAuthentication` resource. Strict mTLS mode is currently not compatible with {{stack}} features requiring TLS to be enabled for the {{es}} HTTP layer.
::::
diff --git a/deploy-manage/deploy/deployment-comparison.md b/deploy-manage/deploy/deployment-comparison.md
index e25291e537..0fab81637e 100644
--- a/deploy-manage/deploy/deployment-comparison.md
+++ b/deploy-manage/deploy/deployment-comparison.md
@@ -41,7 +41,7 @@ For more details about feature availability in {{serverless-short}}, refer to []
| Feature/capability | Fully self-managed, ECE, ECK | ECH | {{serverless-short}} |
|-------------------|-------------------------------|---------|----------------------|
| [Deployment health monitoring](/deploy-manage/monitor.md) | AutoOps or monitoring cluster | AutoOps or monitoring cluster | Managed by Elastic |
-| [Alerting](/explore-analyze/alerting.md) | Watcher or {{kib}} alerts | Watcher or {{kib}} alerts | Alerts ([why?](/explore-analyze/alerting.md#watcher)) |
+| [Alerting](/explore-analyze/alerting-overview.md) | Watcher or {{kib}} alerts | Watcher or {{kib}} alerts | Alerts ([why?](/explore-analyze/alerting-overview.md#watcher)) |
## Data lifecycle
diff --git a/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md b/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md
index fafbd6b906..9102ddc101 100644
--- a/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md
+++ b/deploy-manage/deploy/elastic-cloud/restrictions-known-problems.md
@@ -111,7 +111,7 @@ $$$ec-restrictions-network-security-kibana-sso$$$
## {{kib}} [ec-restrictions-kibana]
* The maximum size of a single {{kib}} instance is 8GB. This means, {{kib}} instances can be scaled up to 8GB before they are scaled out. For example, when creating a deployment with a {{kib}} instance of size 16GB, then 2x8GB instances are created. If you face performance issues with {{kib}} PNG or PDF reports, the recommendations are to create multiple, smaller dashboards to export the data, or to use a third party browser extension for exporting the dashboard in the format you need.
-* Running an external {{kib}} in parallel to {{ecloud}}’s {{kib}} instances may cause errors, for example [`Unable to decrypt attribute`](../../../explore-analyze/alerting/alerts/alerting-common-issues.md#rule-cannot-decrypt-api-key), due to a mismatched [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#security-encrypted-saved-objects-settings) as {{ecloud}} does not [allow users to set](edit-stack-settings.md) nor expose this value. While workarounds are possible, this is not officially supported nor generally recommended.
+* Running an external {{kib}} in parallel to {{ecloud}}’s {{kib}} instances may cause errors, for example [`Unable to decrypt attribute`](../../../explore-analyze/alerting/kibana-alerting-v1/alerting-common-issues-v1.md#rule-cannot-decrypt-api-key), due to a mismatched [`xpack.encryptedSavedObjects.encryptionKey`](kibana://reference/configuration-reference/security-settings.md#security-encrypted-saved-objects-settings) as {{ecloud}} does not [allow users to set](edit-stack-settings.md) nor expose this value. While workarounds are possible, this is not officially supported nor generally recommended.
* Workflows using the `elasticsearch.bulk` step might mishandle bulk operations in Elastic Cloud Hosted. Bulk action metadata (such as `index`, `create`, `update`, or `delete`) can be interpreted as document data, which might cause unexpected behavior for bulk operations beyond basic indexing. The workaround is to use a generic Elasticsearch request action in the workflow to call the Bulk API directly instead of using the `elasticsearch.bulk` step. For more information, refer to [Generic request actions](https://www.elastic.co/docs/explore-analyze/workflows/steps/elasticsearch#generic-request-actions). This issue is fixed in Serverless deployments.
diff --git a/deploy-manage/deploy/elastic-cloud/tools-apis.md b/deploy-manage/deploy/elastic-cloud/tools-apis.md
index ab8f72a451..75d6dbfcd3 100644
--- a/deploy-manage/deploy/elastic-cloud/tools-apis.md
+++ b/deploy-manage/deploy/elastic-cloud/tools-apis.md
@@ -106,7 +106,7 @@ serverless: unavailable
## Elastic Cloud email service
-{{ecloud}} provides a built-in email service used by the preconfigured [email connector](kibana://reference/connectors-kibana/email-action-type.md), available in both {{ech}} deployments and {{serverless-full}} projects. This service can be used to send [alert](/explore-analyze/alerting/alerts.md) notifications and is also supported in {{ech}} by [Watcher](/explore-analyze/alerting/watcher/enable-watcher.md).
+{{ecloud}} provides a built-in email service used by the preconfigured [email connector](kibana://reference/connectors-kibana/email-action-type.md), available in both {{ech}} deployments and {{serverless-full}} projects. This service can be used to send [alert](/explore-analyze/alerting/kibana-alerting-v1.md) notifications and is also supported in {{ech}} by [Watcher](/explore-analyze/alerting/watcher/enable-watcher.md).
### Email service limits
diff --git a/deploy-manage/manage-connectors.md b/deploy-manage/manage-connectors.md
index ac55854511..d9a0160f00 100644
--- a/deploy-manage/manage-connectors.md
+++ b/deploy-manage/manage-connectors.md
@@ -24,7 +24,7 @@ You can find the **{{connectors-ui}}** management page in the navigation menu or
## Required permissions [_required_permissions_2]
-Access to connectors is granted based on your privileges to alerting-enabled features. For more information, go to [Security](../explore-analyze/alerting/alerts/alerting-setup.md#alerting-security).
+Access to connectors is granted based on your privileges to alerting-enabled features. For more information, go to [Security](../explore-analyze/alerting/kibana-alerting-v1/alerting-setup-v1.md#alerting-security).
## Connector networking configuration [_connector_networking_configuration]
@@ -92,6 +92,6 @@ If a connector is missing sensitive information after the import, a **Fix** butt
## Monitoring connectors [monitoring-connectors]
-You can query the [Event log index](/explore-analyze/alerting/alerts/event-log-index.md) to gather information on connector successes and failures.
+You can query the [Event log index](/explore-analyze/alerting/kibana-alerting-v1/event-log-index-v1.md) to gather information on connector successes and failures.
If you're using {{stack}}, then you can also use the [Task Manager health API](/deploy-manage/monitor/kibana-task-manager-health-monitoring.md) to monitor connector performance. However, if connectors fail to run, they will report as successful to Task Manager. The failure stats will not accurately depict connector failures.
diff --git a/deploy-manage/monitor/kibana-task-manager-health-monitoring.md b/deploy-manage/monitor/kibana-task-manager-health-monitoring.md
index 3a4956dead..c2c16dab58 100644
--- a/deploy-manage/monitor/kibana-task-manager-health-monitoring.md
+++ b/deploy-manage/monitor/kibana-task-manager-health-monitoring.md
@@ -114,7 +114,7 @@ The Runtime `status` indicates whether task executions have exceeded any of the
::::{important}
Some tasks (such as [connectors](../manage-connectors.md)) will incorrectly report their status as successful even if the task failed. The runtime and workload block will return data about success and failures and will not take this into consideration.
-To get a better sense of action failures, refer to the [Event log index](../../explore-analyze/alerting/alerts/event-log-index.md) for more accurate context into failures and successes.
+To get a better sense of action failures, refer to the [Event log index](../../explore-analyze/alerting/kibana-alerting-v1/event-log-index-v1.md) for more accurate context into failures and successes.
::::
The Capacity Estimation `status` indicates the sufficiency of the observed capacity. An `OK` status means capacity is sufficient. A `Warning` status means that capacity is sufficient for the scheduled recurring tasks, but non-recurring tasks often cause the cluster to exceed capacity. An `Error` status means that there is insufficient capacity across all types of tasks.
diff --git a/deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md b/deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md
index 9e71ff431b..48607bf990 100644
--- a/deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md
+++ b/deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md
@@ -15,7 +15,7 @@ products:
# Stack monitoring alerts [kibana-alerts]
-The {{stack}} {{monitor-features}} provide [Alerting rules](../../../explore-analyze/alerting/alerts.md) out-of-the box to notify you of potential issues in the {{stack}}. These rules are preconfigured based on the best practices recommended by Elastic. However, you can tailor them to meet your specific needs.
+The {{stack}} {{monitor-features}} provide [Alerting rules](../../../explore-analyze/alerting/kibana-alerting-v1.md) out-of-the box to notify you of potential issues in the {{stack}}. These rules are preconfigured based on the best practices recommended by Elastic. However, you can tailor them to meet your specific needs.
:::{image} /deploy-manage/images/kibana-monitoring-kibana-alerting-notification.png
:alt: {{kib}} alerting notifications in {{stack-monitor-app}}
diff --git a/deploy-manage/monitor/monitoring-data/integrations-server-page.md b/deploy-manage/monitor/monitoring-data/integrations-server-page.md
index d6fc0b2c28..a62f8fdf4d 100644
--- a/deploy-manage/monitor/monitoring-data/integrations-server-page.md
+++ b/deploy-manage/monitor/monitoring-data/integrations-server-page.md
@@ -29,7 +29,7 @@ products:
2. Adjust the time period for the visualizations as needed.
-3. From this page you can also [create alerts](/explore-analyze/alerting/alerts/create-manage-rules.md) to be triggered when the {{integrations-server}} metrics meet a defined set of conditions.
+3. From this page you can also [create alerts](/explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md) to be triggered when the {{integrations-server}} metrics meet a defined set of conditions.
**To view metrics for a specific {{integrations-server}} instance:**
@@ -41,4 +41,4 @@ products:
1. Adjust the time period for the visualizations as needed.
-1. As with the **APM server overview** page, you can also [create alerts](/explore-analyze/alerting/alerts/create-manage-rules.md) to be triggered when the instance metrics meet a defined set of conditions.
+1. As with the **APM server overview** page, you can also [create alerts](/explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md) to be triggered when the instance metrics meet a defined set of conditions.
diff --git a/deploy-manage/production-guidance/kibana-alerting-production-considerations.md b/deploy-manage/production-guidance/kibana-alerting-production-considerations.md
index 23da104fc0..4a775fdba2 100644
--- a/deploy-manage/production-guidance/kibana-alerting-production-considerations.md
+++ b/deploy-manage/production-guidance/kibana-alerting-production-considerations.md
@@ -33,7 +33,7 @@ Rule and action tasks can run late or at an inconsistent schedule. This is typic
You can address such issues by tweaking the [Task Manager settings](kibana://reference/configuration-reference/task-manager-settings.md) or scaling the deployment to better suit your use case.
-For detailed guidance, see [Alerting Troubleshooting](../../explore-analyze/alerting/alerts/alerting-troubleshooting.md).
+For detailed guidance, see [Alerting Troubleshooting](../../explore-analyze/alerting/kibana-alerting-v1/alerting-troubleshooting-v1.md).
::::
diff --git a/deploy-manage/production-guidance/kibana-in-production-environments.md b/deploy-manage/production-guidance/kibana-in-production-environments.md
index 3d38e28ff5..23b656f63c 100644
--- a/deploy-manage/production-guidance/kibana-in-production-environments.md
+++ b/deploy-manage/production-guidance/kibana-in-production-environments.md
@@ -19,7 +19,7 @@ How you deploy {{kib}} largely depends on your use case. If you are the only use
## Scalability
-With the introduction of new capabilities such as [{{kib}} Alerting](/explore-analyze/alerting.md) and the [Detection Rules](/solutions/security/detect-and-alert.md) engine, critical components for [Observability](/solutions/observability.md) and [Security](/solutions/security.md) solutions, the scalability factors have evolved significantly.
+With the introduction of new capabilities such as [{{kib}} Alerting](/explore-analyze/alerting-overview.md) and the [Detection Rules](/solutions/security/detect-and-alert.md) engine, critical components for [Observability](/solutions/observability.md) and [Security](/solutions/security.md) solutions, the scalability factors have evolved significantly.
Now, Kibana’s resource requirements extend beyond user activity. The system must also handle workloads generated by automated processes, such as scheduled alerts, background detection rules, and other periodic tasks. These operations are managed by [{{kib}} Task Manager](./kibana-task-manager-scaling-considerations.md), which is responsible for scheduling, executing, and coordinating all background tasks.
diff --git a/deploy-manage/production-guidance/kibana-task-manager-scaling-considerations.md b/deploy-manage/production-guidance/kibana-task-manager-scaling-considerations.md
index 79c097d696..1ba2763023 100644
--- a/deploy-manage/production-guidance/kibana-task-manager-scaling-considerations.md
+++ b/deploy-manage/production-guidance/kibana-task-manager-scaling-considerations.md
@@ -14,7 +14,7 @@ products:
# {{kib}} task manager: performance and scaling guide [task-manager-production-considerations]
-{{kib}} Task Manager is leveraged by features such as [alerting](/explore-analyze/alerting/alerts.md), [actions](/explore-analyze/alerting/alerts.md#rules-actions), and [reporting](/explore-analyze/report-and-share.md) to run mission critical work as persistent background tasks. These background tasks distribute work across multiple {{kib}} instances. This has three major benefits:
+{{kib}} Task Manager is leveraged by features such as [alerting](/explore-analyze/alerting/kibana-alerting-v1.md), [actions](/explore-analyze/alerting/kibana-alerting-v1.md#rules-actions), and [reporting](/explore-analyze/report-and-share.md) to run mission critical work as persistent background tasks. These background tasks distribute work across multiple {{kib}} instances. This has three major benefits:
- **Persistence**: All task state and scheduling is stored in {{es}}, so if you restart {{kib}}, tasks will pick up where they left off.
- **Scaling**: Multiple {{kib}} instances can read from and update the same task queue in {{es}}, allowing the work load to be distributed across instances. If a {{kib}} instance no longer has capacity to run tasks, you can increase capacity by adding additional {{kib}} instances.
diff --git a/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md b/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md
index 131c05a7da..db9be3b164 100644
--- a/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md
+++ b/deploy-manage/users-roles/cluster-or-deployment-auth/quickstart.md
@@ -20,7 +20,7 @@ This guide introduces you to three basic user and access management features: [s
Do you have multiple teams using {{kib}}? Do you want a “playground” to experiment with new visualizations or rules? If so, then [{{kib}} Spaces](../../manage-spaces.md) can help.
-Think of a space as another instance of {{kib}}. A space allows you to organize your [dashboards](../../../explore-analyze/dashboards.md), [rules](../../../explore-analyze/alerting/alerts.md), [machine learning jobs](../../../explore-analyze/machine-learning/machine-learning-in-kibana.md), and much more into their own categories. For example, you might have a **Marketing** space for your marketers to track the results of their campaigns, and an **Engineering** space for your developers to [monitor application performance](/solutions/observability/apm/index.md).
+Think of a space as another instance of {{kib}}. A space allows you to organize your [dashboards](../../../explore-analyze/dashboards.md), [rules](../../../explore-analyze/alerting/kibana-alerting-v1.md), [machine learning jobs](../../../explore-analyze/machine-learning/machine-learning-in-kibana.md), and much more into their own categories. For example, you might have a **Marketing** space for your marketers to track the results of their campaigns, and an **Engineering** space for your developers to [monitor application performance](/solutions/observability/apm/index.md).
The assets you create in one space are isolated from other spaces, so when you enter a space, you only see the assets that belong to that space.
diff --git a/docs/manifests/alerting-v2.yaml b/docs/manifests/alerting-v2.yaml
new file mode 100644
index 0000000000..8866b7b86e
--- /dev/null
+++ b/docs/manifests/alerting-v2.yaml
@@ -0,0 +1,1095 @@
+# docs/manifests/alerting-v2.yaml
+#
+# Maps alerting v2 documentation pages to their Kibana implementation PRs
+# and codebase locations. Used by Docs Patrol External and the workflow
+# docs skill to detect changes that require documentation updates.
+#
+# Owner: docs team (@nastasha-solomon)
+# Last updated: 2026-04-17
+# Docs PR: https://github.com/elastic/docs-content/pull/5528
+
+feature: alerting-v2
+feature_label: Kibana Alerting v2
+status: in-progress
+doc_set:
+ serverless: preview
+ stack: ga # v1 content; v2 stack availability TBD (since 9.4)
+
+# NOTE — index rename chain:
+# Original (247464): .alerts-events .alerts-actions
+# After 254901: .alerting-events .alerting-actions
+# After 258651: .rule-events .alert-actions ← current / final
+# Every page that references index names must use the final names (.rule-events, .alert-actions).
+# ESQL views also renamed in 258651: $.alerting-episodes → $.alert-episodes,
+# $.alerting-events → $.rule-events, $.alerting-actions → $.alert-actions.
+
+# Implementation PRs — add new entries as features ship
+implementation_prs:
+
+ # --- Foundational ---
+
+ - url: https://github.com/elastic/kibana/pull/247464
+ title: "[ResponseOps][Alerting] Alerting v2"
+ summary: >
+ Foundational v2 alerting framework — core rule engine, scheduling and execution
+ architecture, ES|QL-native rule evaluation, alert lifecycle management, dispatcher,
+ action policies CRUD and UI, rule authoring UI (standalone and embedded in
+ Discover), rule management UI, APM instrumentation, and InversifyJS DI wiring.
+ This is an umbrella PR covering ~50 sub-PRs across engine, UI, and infrastructure.
+ author: cnasikas
+
+ # --- Index renames (two-step; see chain note above) ---
+
+ - url: https://github.com/elastic/kibana/pull/254901
+ title: "[ResponseOps][AlertingV2] Rename indexes for alert events and actions"
+ summary: >
+ First rename: `.alerts-events` → `.alerting-events`, `.alerts-actions` → `.alerting-actions`.
+ Superseded by PR #258651, which performs the second (final) rename.
+ Retained in the manifest because some doc files were drafted against these intermediate names.
+ author: adcoelho
+
+ - url: https://github.com/elastic/kibana/pull/258651
+ title: "[Alerting V2] Rename indices and ESQL views"
+ summary: >
+ Second (final) rename: `.alerting-events` → `.rule-events`, `.alerting-actions` → `.alert-actions`.
+ Also renames ES|QL views: `$.alerting-episodes` → `$.alert-episodes`,
+ `$.alerting-events` → `$.rule-events`, `$.alerting-actions` → `$.alert-actions`.
+ All doc pages that reference index or view names must be updated to these final values.
+ Supersedes PR #254901.
+ author: adcoelho
+
+ # --- Alert actions and episodes ---
+
+ - url: https://github.com/elastic/kibana/pull/258353
+ title: "[Alerting V2] bulk get alert actions"
+ summary: >
+ Adds `POST /internal/alerting/v2/alerts/action/_bulk_get` for retrieving action records
+ for multiple episode IDs in one request. Required to display per-episode status in the
+ alert episodes table UI.
+ author: adcoelho
+
+ - url: https://github.com/elastic/kibana/pull/258643
+ title: "[Alerting V2] Remove 'untag' alert action"
+ summary: >
+ Removes the `untag` action type from the alert actions schema. Tags are now managed
+ exclusively via the `tag` action. The bulk-get query now returns the last `tag` action
+ per episode. Affects investigate-respond.md (action type table) and any UI docs listing
+ available alert actions.
+ author: adcoelho
+
+ - url: https://github.com/elastic/kibana/pull/257347
+ title: "[Alerting V2] Update the alert episodes view query."
+ summary: >
+ Updates the ES|QL view query for alert episodes to include episode duration.
+ Surfaces the Duration column in the alert list UI and alert episode detail view.
+ author: adcoelho
+
+ # --- Alert episodes UI (list, detail, filters, row actions, Discover) ---
+
+ - url: https://github.com/elastic/kibana/pull/260218
+ title: "[ResponseOps][Alerting v2] Episodes page minimal filtering, searching and sorting"
+ summary: >
+ Episodes table: UnifiedDataGrid sorting; **Rule** and **Status** filters; debounced text search
+ on alert document fields (rule metadata not fully searchable until future rule lookup work).
+ Pagination removed in favor of a 1000-row cap and footer callout; fixes duration as milliseconds
+ and episodes query index `.rule-events`. Rule bulk-get accepts single string IDs.
+ author: umbopepato
+
+ - url: https://github.com/elastic/kibana/pull/260195
+ title: "[Alerting V2] Episode table actions"
+ summary: >
+ Episodes table actions from `.alert-actions`: **Snooze** / **Unsnooze** per `group_hash` (popover;
+ bell + expiry in status column); **Acknowledge** / **Unacknowledge** per episode; **Resolve** /
+ **Unresolve** per group (UI forces `inactive`); **Tags** display (tagging via API in this PR).
+ Per-action-type HTTP routes (public). Split episode vs group actions in the table.
+ author: adcoelho
+
+ - url: https://github.com/elastic/kibana/pull/260942
+ title: "[ResponseOps][Alerting v2] Episode details page"
+ summary: >
+ Full **episode detail page**: lifecycle heatmap, related episodes, grouping, filters, actions
+ shared with the list. Moves the episodes list into the `alerting_v2` plugin under **Stack Management**
+ navigation; refactors `@kbn/alerting-v2-episodes-ui` and adds related-episodes fetch wiring.
+ Observability may still deep-link; primary ownership shifts from PR #257638 o11y-only scope.
+ author: umbopepato
+
+ - url: https://github.com/elastic/kibana/pull/261966
+ title: "[Alerting V2] Edit episode tags"
+ summary: >
+ **Edit tags** on the alert episodes table and episode detail page: flyout with suggestions from
+ top episode tags plus new tag entry. v2-specific implementation (not reused from v1 alerts table).
+ author: adcoelho
+
+ - url: https://github.com/elastic/kibana/pull/262288
+ title: "[ResponseOps][Alerting v2] Implement episodes list filter by tags"
+ summary: >
+ **Tags** filter on the episodes list: multi-select with OR semantics on last tag set
+ (`MV_CONTAINS` / `last_tags`); tag options ES|QL capped at 500 rows; composes with rule, status,
+ search, and time range; cache invalidation when tags change (with PR #261966).
+ author: umbopepato
+
+ - url: https://github.com/elastic/kibana/pull/262459
+ title: "Add link to discover in alert episodes."
+ summary: >
+ **Discover** link from the alert episodes table: opens Discover with the rule ES|QL query and
+ absolute time ±15 minutes around the episode timestamp.
+ author: adcoelho
+
+ - url: https://github.com/elastic/kibana/pull/256527
+ title: "Store 'unmatched' action for unmatched alert episodes"
+ summary: >
+ Fixes a dispatcher bug where alert episodes matching no action policy were
+ silently dropped and re-fetched every run. Now persists them with
+ `action_type: 'unmatched'` and reason `'no matching notification policy'`,
+ and adds `unmatched` to the fetch query's INLINE STATS filter.
+ Affects dispatcher pipeline docs, action policy evaluation docs, and the
+ alert actions field reference.
+ author: kdelemme
+
+ # --- Dispatcher pipeline (suppression, policy fetch, dispatch) ---
+
+ - url: https://github.com/elastic/kibana/pull/256486
+ title: "Fix suppression query"
+ summary: >
+ Replaces a left-associative OR chain in `getAlertEpisodeSuppressionsQuery` with a
+ concat + WHERE IN pattern so large episode batches do not exceed the ES|QL parser
+ expression depth limit. Affects dispatcher suppression logic against `.alert-actions`.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/256536
+ title: "Use stored encrypted API keys from Notification Policy in dispatcher step to trigger workflow"
+ summary: >
+ Wires `DispatchStep` to decrypt the policy API key via ESO, build a scoped
+ `KibanaRequest`, and run workflow destinations through `WorkflowsManagementApi`.
+ Adds `bulkGetDecryptedByIds` on the action policy saved object service and
+ refactors `FetchPoliciesStep` to populate decrypted keys in pipeline state.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/259182
+ title: "feat(alertingv2): make dispatcher space-aware"
+ summary: >
+ Derives `spaceId` from saved object namespaces for rules and action policies;
+ enforces same-space matching in the dispatcher; resolves workflows in the policy's
+ space instead of a hardcoded default. Touches FetchRulesStep, FetchPoliciesStep,
+ EvaluateMatchersStep, BuildGroupsStep, and DispatchStep.
+ author: kdelemme
+
+ # --- Action policies (docs); implementation paths may still use notification_policy ---
+
+ - url: https://github.com/elastic/kibana/pull/253134
+ title: "chore(rna): update notification policy"
+ summary: >
+ Major action policy schema alignment: replaces `workflow_id` with a
+ typed `destinations` array; adds optional `matcher`, `group_by`, and `throttle`;
+ moves shared Zod types into `@kbn/alerting-v2-schemas`; adds `getNotificationPolicies({ ids })`
+ and SO `bulkGetByIds` for dispatcher batch fetch. Docs should use destinations/matcher
+ terminology and final field casing from follow-up PR #258237.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/254808
+ title: "Store API key owner on Notification Policy"
+ summary: >
+ Stores encrypted ES or UIAM API key on the action policy saved object (ESO),
+ with `apiKeyOwner` / `apiKeyCreatedByUser` as AAD fields; creates or rotates keys on
+ create/update; strips secrets from API responses. Precedes dispatcher use in PR #256536
+ and invalidation flow in PRs #257377 / #258094.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/256759
+ title: "[Alerting v2] Add enable, disable, snooze and bulk action routes for notification policies"
+ summary: >
+ Adds `_enable`, `_disable`, `_snooze`, and `_bulk` routes; introduces `enabled` and
+ `snoozedUntil` on the policy SO; dispatcher `EvaluateMatchersStep` skips disabled or
+ snoozed policies; bulk state updates use `bulkUpdate`.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/256940
+ title: "Make notification policies global with optional rule-label scoping"
+ summary: >
+ Decouples action policies from rules. Policies are now global — all policies are
+ evaluated for every alert episode by default. Rules no longer reference specific policies
+ via `notification_policies: [{ ref: policyId }]`. An optional `rule_labels` field on
+ the policy scopes it to rules whose `metadata.labels` match. The dispatcher fetches all
+ policies every tick via `findAllDecrypted()`. The Step 6 matcher now uses two-phase matching:
+ first rule-label scoping (empty `ruleLabels` = catch-all), then KQL episode evaluation.
+ Affects action policy schema docs, create/manage how-to, and dispatcher pipeline docs.
+ Superseded in part by PR #257279 (rule-aware KQL and removal of `rule_labels` from the SO).
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/257279
+ title: "[Alerting v2] Add search, filtering, sorting, and state management to notification policies"
+ summary: >
+ Extends the list policies API with search, filter, and sort query params; adds UI for
+ list filtering and per-row enable/disable/snooze/unsnooze; adds unsnooze and bulk
+ state routes. Removes `rule_labels` from the policy SO and form — matcher KQL is
+ evaluated with episode + rule context (`EvaluateMatchersStep`); extends `kbn-eval-kql`
+ for array membership. Overlaps with PR #256759 for state APIs and PR #258862 for bulk list actions.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/258010
+ title: "Add dynamic workflow selection to notification policy form"
+ summary: >
+ Replaces hardcoded workflow options in the policy form with dynamic search via the
+ `/api/workflows/search` API. Users can now search and select real workflows when
+ creating or editing a policy. Affects create/manage action policy how-to docs.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/258917
+ title: "[Alerting v2] Replace custom matcher input with KQL QueryStringInput"
+ summary: >
+ Replaces the custom `MatcherInput` with KQL's `QueryStringInput`, adding syntax
+ highlighting, autocomplete, and validation. Defines a typed `MatcherContext` schema
+ with field descriptors (`MATCHER_CONTEXT_FIELDS`) so the input auto-suggests valid
+ field names: `episode_status`, `rule.name`, `rule.labels`, and `data.*` fields.
+ Affects any doc describing the action policy matcher field.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/258237
+ title: "[Alerting v2] align notification policy casing to camelCase"
+ summary: >
+ Aligns policy request/response, saved object, UI, and dispatcher contracts to camelCase
+ (`groupBy`, `snoozedUntil`, etc.); fixes partial updates and field clearing; adds
+ `createdByUsername` / `updatedByUsername`; list UI shows workflow count popover and
+ removes redundant filters. Docs and examples must use camelCase field names.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/259114
+ title: "feat(alertingv2): update list notification policies table"
+ summary: >
+ Follow-up UX and table behavior for the action policies list page
+ (builds on PR #257279). Track for list-page screenshots, column labels, and bulk/row actions docs.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/258862
+ title: "[Alerting v2] Add bulk actions for notification policies"
+ summary: >
+ Adds bulk enable, disable, snooze, and delete actions to the action policies
+ list page, including confirmation modals for destructive operations.
+ Affects create/manage action policy how-to and any policy management reference.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/259390
+ title: "[Alerting v2] Add update API key for notification policies"
+ summary: >
+ Adds `POST .../notification_policies/{id}/_update_api_key` to rotate the policy API key
+ without changing other attributes; extends bulk actions with `update_api_key`; surfaces
+ “Update API key” in the list UI (row and bulk). Complements PRs #257377 and #258094.
+ author: kdelemme
+
+ - url: https://github.com/elastic/kibana/pull/257377
+ title: "[Alerting V2] mark np api keys for invalidation"
+ summary: >
+ Introduces a saved object type for pending API key invalidations. When an action
+ policy is updated, the old API key is marked for invalidation and a new one is created.
+ When deleted, the API key is marked for invalidation. Related to PR #258094 which
+ schedules the actual invalidation task.
+ author: adcoelho
+
+ - url: https://github.com/elastic/kibana/pull/258094
+ title: "[Alerting V2] Schedule task for notification policies API key invalidation"
+ summary: >
+ Introduces a recurring Task Manager task (`alerting_v2:invalidate_api_keys`) that
+ invalidates API keys marked for removal (pending invalidation SOs). Configurable via:
+ `xpack.alerting_v2.invalidateApiKeysTask.interval` (default: `5m`)
+ `xpack.alerting_v2.invalidateApiKeysTask.removalDelay` (default: `1h`)
+ Affects setup/configuration docs and production considerations.
+ author: adcoelho
+
+ # --- Rule authoring UI ---
+
+ - url: https://github.com/elastic/kibana/pull/255734
+ title: "[Alerting V2] [UI] Add no-data handling feature to rule form"
+ summary: >
+ Adds the No-data handling control block to the v2 rule form. Controls are visible
+ for `kind=alert` only; hidden for `kind=signal`. Adds `noData.behavior` and related
+ fields to the rule schema. Affects author-rules/rule-settings.md (no-data section) and
+ author-rules/create-rule-from-rule-builder.md.
+ author: yiannisnikolopoulos
+
+ - url: https://github.com/elastic/kibana/pull/257324
+ title: "[Alerting v2] rule form - preview chart"
+ summary: >
+ Adds a Lens-powered bar chart histogram to the rule preview panels (evaluation and
+ recovery), showing the count of matching rows over time. Affects create-rule-from-rule-builder.md
+ and any doc describing the rule form preview experience.
+ author: dominiqueclarke
+
+ # --- Rule management UI ---
+
+ - url: https://github.com/elastic/kibana/pull/256260
+ title: "[Alerting v2] foundational rule list"
+ summary: >
+ Rewrites the v2 rules list with EuiBasicTable and React Query (paginated list,
+ create/edit/delete flows, delete confirmation). Precursor to rule details, filters,
+ and bulk operations. Affects manage-rules docs for list columns and navigation.
+ author: dominiqueclarke
+
+ - url: https://github.com/elastic/kibana/pull/256692
+ title: "[Alerting v2] Rule Details Page"
+ summary: >
+ Implements the v2 rule details page: header with rule name, kind (Detect/Alert)
+ badge, enabled/disabled state, tags, rule conditions (ES|QL base query and alert
+ condition section), and rule-level actions. Affects manage-rules.md.
+ author: yiannisnikolopoulos
+
+ - url: https://github.com/elastic/kibana/pull/258341
+ title: "[Alerting v2] rule list bulk enable disable delete select all"
+ summary: >
+ Adds bulk operations (enable, disable, delete) and select-all to the v2 rules list.
+ Affects manage-rules.md.
+ author: dominiqueclarke
+
+ - url: https://github.com/elastic/kibana/pull/260233
+ title: "[RnA - Alerting V2] Add filtering and sorting to the rule list (name, mode, tags, status)"
+ summary: >
+ Server-side filters (enabled, mode, labels), search, column sorting, tag facet API
+ (`GET /internal/alerting/v2/rule/_tags`), and pagination reset when query changes.
+ Affects manage-rules.md.
+ author: ana-davydova
+
+ - url: https://github.com/elastic/kibana/pull/260270
+ title: "[Alerting v2] Runbook UI"
+ summary: >
+ Adds a Conditions | Runbook tab bar on the rule details page; renders runbook markdown
+ from runbook artifacts. Extends PR #256692. Affects rule details documentation.
+ author: baileycash-elastic
+
+ - url: https://github.com/elastic/kibana/pull/261442
+ title: "[Alerting v2] Bulk rules ops: 10k cap, list filter scope, and UI disclosure"
+ summary: >
+ Caps filter-based bulk enable/disable/delete at 10,000 rules with truncation metadata;
+ select-all bulk operations respect active list filters and search (shared KQL with the
+ list API). Builds on PR #258341.
+ author: dominiqueclarke
+
+ # --- Alerting v2 navigation (Management URLs and solution entry points) ---
+
+ - url: https://github.com/elastic/kibana/pull/260355
+ title: "Alerting v2 navigation updates"
+ summary: >
+ Registers a dedicated Management section "V2 Alerting Preview" with separate Rules and
+ Notification Policies apps, new `/app/management/alertingV2/*` URLs, BreadcrumbContext
+ for serverless, and solution/serverless nav links (Observability, Security ESS, Search,
+ Enterprise Search) gated by `alertingVTwo`. Docs must stay aligned with navigation paths.
+ author: baileycash-elastic
+
+ - url: https://github.com/elastic/kibana/pull/260798
+ title: "Add V2 Alerting Preview to Security ESS navigation"
+ summary: >
+ Follow-up to PR #260355: adds the capability-gated "V2 Alerting Preview" section under
+ Stack Management in the Security ESS solution navigation (`management:rules`,
+ `management:notification_policies` deep links).
+ author: baileycash-elastic
+
+ # --- Discover: create-rule entry point ---
+
+ - url: https://github.com/elastic/kibana/pull/260844
+ title: "Move v2 ES|QL rule creation into Discover Alerts menu"
+ summary: >
+ Moves "Create ES|QL rule" into the Discover Alerts popover (with a New badge) instead of
+ a separate top-level Rules menu item; closes rna-program#292. Affects create-rule-from-rule-builder.md
+ and Discover integration docs.
+ author: dominiqueclarke
+
+ # --- RnA program (cross-repo tracking) ---
+
+ - url: https://github.com/elastic/rna-program/issues/115
+ title: "[RnA program] Issue #115"
+ summary: >
+ Program-level tracking in elastic/rna-program; use the issue for scope and acceptance
+ criteria alongside Kibana PRs (issue may be private).
+ author: rna-program
+
+ # --- Observability integration ---
+
+ - url: https://github.com/elastic/kibana/pull/257638
+ title: "[ResponseOps][RnA] Minimal alerting episodes o11y page"
+ summary: >
+ Foundational alerting episodes experience in Observability at `/app/observability/alerts_v2`:
+ creates `@kbn/alerting-v2-episodes-ui` (components, ES|QL fetch hooks, episode status badge).
+ List/detail navigation and Stack Management placement evolved in PR #260942; keep this entry
+ for package origin and Observability entry points. Doc page still TBD — see `alerting-v2-o11y-episodes`.
+ author: umbopepato
+
+ # --- Rule execution history ---
+
+ - url: https://github.com/elastic/kibana/pull/254990
+ title: "[AlertingV2] Rule execution history and status"
+ summary: >
+ Adds event log integration to Task Manager to record rule execution outcomes
+ (success, failure, cancelled) in `.kibana-event-log*`. No corresponding doc
+ page exists yet — flagged as a docs gap.
+ author: doakalexi
+
+
+entries:
+
+ # ---------------------------------------------------------------------------
+ # Top-level navigation and overview pages
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-overview-main
+ content_type: conceptual
+ docs_file: explore-analyze/alerting-overview.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/
+ - x-pack/platform/plugins/shared/alerting/public/
+ doc_set:
+ serverless: preview
+ stack: ga
+ notes: >
+ Top-level alerting landing page. Covers all three alerting systems (v1, v2, Watcher).
+ Review when any system changes significantly or when v2 reaches GA on stack.
+
+ - id: alerting-landing
+ content_type: conceptual
+ docs_file: explore-analyze/alerting.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/
+ doc_set:
+ serverless: preview
+ stack: ga
+ notes: >
+ Section landing page / TOC for the alerting area. Review if the IA changes
+ (new v2 sections added, v1 deprecated, Watcher removed).
+
+ - id: alerting-choose-system
+ content_type: conceptual
+ docs_file: explore-analyze/alerting/choose-an-alerting-system.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/
+ doc_set:
+ serverless: preview
+ notes: >
+ Comparison guide: v1 vs v2 vs Watcher. Needs review when feature parity between
+ v1 and v2 changes, when v2 reaches GA, or when v1 deprecation is announced.
+ This page will need significant revision at each of those milestones.
+
+ # ---------------------------------------------------------------------------
+ # Kibana alerting v1 (existing, reorganized under new IA)
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v1
+ content_type: conceptual
+ docs_file: explore-analyze/alerting/kibana-alerting-v1/
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs: []
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/
+ - x-pack/platform/plugins/shared/alerting/public/
+ doc_set:
+ serverless: ga
+ stack: ga
+ notes: >
+ Existing v1 alerting docs, reorganized under the new alerting IA. Content largely
+ stable. Review if v1 feature set changes or if v1 deprecation is announced.
+ Covers: getting started, setup, create/manage rules, rule types, action variables,
+ event log, maintenance windows, notifications allowlist, troubleshooting.
+
+ # ---------------------------------------------------------------------------
+ # {{alerting-v2}} — hub (conceptual landing + glossary)
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-overview
+ content_type: conceptual
+ docs_file: explore-analyze/alerting/kibana-alerting-v2.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/260355
+ - https://github.com/elastic/kibana/pull/260798
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/
+ - x-pack/platform/plugins/shared/alerting/public/
+ doc_set:
+ serverless: preview
+ notes: >
+ V2 alerting section hub: conceptual overview, glossary, and setup order. Review on major v2
+ architectural changes or when new top-level v2 capabilities ship.
+ PRs #260355 / #260798 — solution and Management entry points for the v2 apps;
+ keep high-level "where to open Rules V2" language consistent with get-starting.md (setup).
+
+ # ---------------------------------------------------------------------------
+ # {{alerting-v2}} — send notifications (hub; peers with Getting started, Author rules, etc.)
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-send-notifications
+ content_type: conceptual
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/notifications.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/notification_policy/
+ - x-pack/platform/plugins/shared/alerting/server/dispatcher/
+ doc_set:
+ serverless: preview
+ notes: >
+ Landing page for the "Send notifications" IA bucket. Links to action policies,
+ matcher/grouping/throttle under action-policies/, and canonical Workflows docs.
+
+ # ---------------------------------------------------------------------------
+ # {{alerting-v2}} — get started (setup, privileges, concepts siblings)
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-get-started
+ content_type: conceptual
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/get-started.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/feature.ts
+ - x-pack/platform/plugins/shared/alerting/server/routes/
+ doc_set:
+ serverless: preview
+ notes: >
+ Get started hub: enable/verify UI, data streams, stack requirements, privileges,
+ spaces/API keys, optional `kibana.yml` invalidation settings, next-step links.
+ alerting-v2-set-up is the procedural manifest entry for the same file.
+
+ - id: alerting-v2-set-up
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/get-started.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/254901
+ - https://github.com/elastic/kibana/pull/258651
+ - https://github.com/elastic/kibana/pull/258094
+ - https://github.com/elastic/kibana/pull/260355
+ - https://github.com/elastic/kibana/pull/260798
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/data_streams/
+ - x-pack/platform/plugins/shared/alerting/server/index.ts
+ - x-pack/platform/plugins/shared/alerting/server/task_manager/
+ doc_set:
+ serverless: preview
+ notes: >
+ Setup and verify (enablement, `.rule-events` / `.alert-actions`, UI checks) and
+ `kibana.yml` invalidation task settings; lives on get-started.md with setup and verify.
+ High-priority for updates on three counts:
+ • Index rename chain — final names are `.rule-events` and `.alert-actions`
+ (see chain note at top of file). The current draft uses `.alerts-events-*` and
+ `.alerts-actions`; these must be updated.
+ • PR #258094 — adds a new Task Manager task for API key invalidation with two
+ configurable Kibana settings to document:
+ `xpack.alerting_v2.invalidateApiKeysTask.interval` (default: `5m`)
+ `xpack.alerting_v2.invalidateApiKeysTask.removalDelay` (default: `1h`)
+ • PRs #260355 / #260798 — Management and solution navigation for v2 (dedicated
+ "V2 Alerting Preview" section, `/app/management/alertingV2/*` apps, solution nav
+ entry points). Review every UI navigation step in this page for path and label drift
+ versus "Alerts and Insights > Rules V2" wording in older drafts.
+
+ # ---------------------------------------------------------------------------
+ # {{alerting-v2}} — author rules
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-author-rules
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/rules/author-rules.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/255734
+ - https://github.com/elastic/kibana/pull/257324
+ - https://github.com/elastic/kibana/pull/260844
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/rules/
+ - x-pack/platform/plugins/shared/alerting/server/rules_client/
+ - x-pack/platform/plugins/shared/alerting/public/pages/rules/
+ - packages/kbn-alerting-v2-rule-form/
+ doc_set:
+ serverless: preview
+ notes: >
+ Rule authoring concepts (ES|QL, modes, conditions). Create flows live on
+ create-rule-from-rule-builder.md, create-rule-from-discover.md, and create-rule-with-yaml.md.
+ Also covers: rule templates; rules on alerts; set data sources;
+ production considerations; rule-settings.md (schedule, thresholds, no-data, grouping,
+ maintenance). Action policies and workflow integration: notifications.md and workflows-alerting-v2.md.
+ • PR #255734 — no-data handling UI now live in the rule form (kind=alert only);
+ rule-settings.md no-data section needs to reflect the form controls and the `noData.behavior` field.
+ • PR #257324 — preview chart added to rule form (Lens histogram showing matching
+ row counts over time for evaluation and recovery previews). create-rule-from-rule-builder.md
+ should describe this panel.
+ • PR #260844 — Discover: create ES|QL rule moved into the Alerts menu popover (with
+ a New badge) instead of a separate top-level Rules entry; update create-rule-from-rule-builder.md
+ steps that reference Discover navigation.
+ See separate entries for action-policies pages, which track additional PRs.
+
+ - id: alerting-v2-action-policies
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/notifications.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/253134
+ - https://github.com/elastic/kibana/pull/254808
+ - https://github.com/elastic/kibana/pull/256527
+ - https://github.com/elastic/kibana/pull/256759
+ - https://github.com/elastic/kibana/pull/256940
+ - https://github.com/elastic/kibana/pull/257279
+ - https://github.com/elastic/kibana/pull/258010
+ - https://github.com/elastic/kibana/pull/258237
+ - https://github.com/elastic/kibana/pull/258917
+ - https://github.com/elastic/kibana/pull/259114
+ - https://github.com/elastic/kibana/pull/258862
+ - https://github.com/elastic/kibana/pull/259390
+ - https://github.com/elastic/kibana/pull/257377
+ - https://github.com/elastic/kibana/pull/258094
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/notification_policy/
+ - x-pack/platform/plugins/shared/alerting/public/pages/notification_policies/
+ doc_set:
+ serverless: preview
+ notes: >
+ Overview page for action policies. Several significant implementation changes
+ affect the conceptual description of what policies are and how they work:
+ • PR #253134 / #258237 — policy shape uses `destinations`, optional `matcher`, `groupBy`,
+ `throttle`; camelCase API/SO contracts.
+ • PR #254808 / #259390 — encrypted API keys on policies; optional manual key rotation route
+ and bulk `update_api_key`; invalidation via PRs #257377 and #258094.
+ • PR #256940 — Policies are global (not rule-linked by ID). PR #257279 removes `rule_labels`
+ from the SO; scoping is via KQL matcher with rule fields in context.
+ • PR #256527 — describes what happens when no policy matches an episode (`unmatched`).
+ • PR #256759 — `enabled` / `snoozedUntil`; dispatcher skips disabled or snoozed policies.
+ • PR #257279 / #259114 — list page search, filters, sort, state badges, and table UX.
+ • PR #258917 — matcher uses KQL `QueryStringInput`; context includes `rule.name`, `rule.labels`, etc.
+ • PR #258862 — bulk enable, disable, snooze, delete (and related list actions).
+ • PR #258010 — workflow selection is dynamic (search-based).
+
+ - id: alerting-v2-create-action-policies
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/253134
+ - https://github.com/elastic/kibana/pull/254808
+ - https://github.com/elastic/kibana/pull/256759
+ - https://github.com/elastic/kibana/pull/256940
+ - https://github.com/elastic/kibana/pull/257279
+ - https://github.com/elastic/kibana/pull/258010
+ - https://github.com/elastic/kibana/pull/258237
+ - https://github.com/elastic/kibana/pull/258917
+ - https://github.com/elastic/kibana/pull/259114
+ - https://github.com/elastic/kibana/pull/258862
+ - https://github.com/elastic/kibana/pull/259390
+ - https://github.com/elastic/kibana/pull/257377
+ - https://github.com/elastic/kibana/pull/258094
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/notification_policy/
+ - x-pack/platform/plugins/shared/alerting/public/pages/notification_policies/
+ doc_set:
+ serverless: preview
+ notes: >
+ CRUD how-to for action policies.
+ • PR #253134 / #258237 — document `destinations`, matcher, `groupBy`, throttle, and camelCase fields.
+ • PR #256940 / #257279 — policies are global; matcher KQL can reference rule metadata (no `rule_labels` field on SO after #257279).
+ • PR #256759 — enable, disable, snooze, unsnooze, and bulk state APIs.
+ • PR #258010 — workflow selector is a dynamic search field.
+ • PR #257279 / #259114 — list page search, filters, sort, row actions, and table refinements.
+ • PR #258862 — bulk enable, disable, snooze, delete from the list UI.
+ • PR #259390 — “Update API key” row and bulk action.
+ • PR #257377 / #258094 — key rotation and scheduled invalidation (`xpack.alerting_v2.invalidateApiKeysTask.*`).
+
+ - id: alerting-v2-action-policy-reference
+ content_type: reference
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/notifications/action-policy-reference.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/253134
+ - https://github.com/elastic/kibana/pull/256759
+ - https://github.com/elastic/kibana/pull/256940
+ - https://github.com/elastic/kibana/pull/257279
+ - https://github.com/elastic/kibana/pull/258237
+ - https://github.com/elastic/kibana/pull/258917
+ - https://github.com/elastic/kibana/pull/259114
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/notification_policy/
+ - x-pack/platform/plugins/shared/alerting/public/pages/notification_policies/
+ doc_set:
+ serverless: preview
+ notes: >
+ Consolidated API and UI mapping tables for matchers, grouping, throttling, dispatch outcomes,
+ and workflow destinations. Split from create-configure-action-policy.md.
+
+ - id: alerting-v2-action-policies-eval
+ content_type: conceptual
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/notifications.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/253134
+ - https://github.com/elastic/kibana/pull/256486
+ - https://github.com/elastic/kibana/pull/256527
+ - https://github.com/elastic/kibana/pull/256536
+ - https://github.com/elastic/kibana/pull/256759
+ - https://github.com/elastic/kibana/pull/256940
+ - https://github.com/elastic/kibana/pull/257279
+ - https://github.com/elastic/kibana/pull/258237
+ - https://github.com/elastic/kibana/pull/258917
+ - https://github.com/elastic/kibana/pull/259182
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/dispatcher/
+ - x-pack/platform/plugins/shared/alerting/server/dispatcher/steps/store_actions_step.ts
+ - x-pack/platform/plugins/shared/alerting/server/dispatcher/steps/evaluate_matchers_step.ts
+ doc_set:
+ serverless: preview
+ notes: >
+ Documents the dispatcher pipeline and policy evaluation:
+ • PR #256486 — suppression query against alert actions avoids deep OR trees (WHERE IN pattern).
+ • PR #256536 — dispatch runs workflows using decrypted policy API keys (FetchPolicies + Dispatch steps).
+ • PR #259182 — space-aware fetch, matching, and workflow execution (`spaceId` from namespaces).
+ • PR #256759 — disabled or snoozed policies are skipped during matcher evaluation.
+ • PR #256940 — Step 4 fetches policies via `findAllDecrypted()` / global policy model.
+ • PR #257279 — removes `rule_labels` from policies; Step 6 evaluates KQL against episode + rule context;
+ array membership support in KQL evaluator.
+ • PR #256527 — `unmatched` outcome when no policy matches (stored reason may still use the string `no matching notification policy`).
+ • PR #258917 — KQL matcher UI and `MatcherContext` fields (`episode_status`, `rule.name`, `rule.labels`, `data.*`).
+ • PR #253134 / #258237 — policy shape (`destinations`, etc.) and camelCase fields flow through the pipeline.
+
+ # ---------------------------------------------------------------------------
+ # {{alerting-v2}} — manage alerts
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-manage-alerts
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/alerts/view-manage-and-reference-alerts.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/alerts/
+ - x-pack/platform/plugins/shared/alerting/public/pages/alerts/
+ doc_set:
+ serverless: preview
+ notes: >
+ How-to content for managing and triaging alerts. See per-file entries below
+ for manage-alerts (episodes table), alert-states-and-fields-reference, explore-alerts-discover,
+ and investigate-respond (episode detail + alert actions consolidated).
+
+ - id: alerting-v2-view-alerts
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/alerts/view-manage-and-reference-alerts.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/257638
+ - https://github.com/elastic/kibana/pull/258353
+ - https://github.com/elastic/kibana/pull/257347
+ - https://github.com/elastic/kibana/pull/258643
+ - https://github.com/elastic/kibana/pull/260218
+ - https://github.com/elastic/kibana/pull/260195
+ - https://github.com/elastic/kibana/pull/260942
+ - https://github.com/elastic/kibana/pull/261966
+ - https://github.com/elastic/kibana/pull/262288
+ - https://github.com/elastic/kibana/pull/262459
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/public/pages/alerts/
+ - x-pack/platform/plugins/shared/alerting_v2/public/pages/
+ - packages/kbn-alerting-v2-episodes-ui/
+ - x-pack/platform/plugins/shared/alerting/server/routes/alerts/bulk_get_alert_actions.ts
+ doc_set:
+ serverless: preview
+ notes: >
+ Alert inbox / alert episodes table: triage, filters, sorting, row actions, Discover link.
+ • PR #257638 — initial Observability episodes page and `@kbn/alerting-v2-episodes-ui` package.
+ • PR #257347 — Duration column (episode view query).
+ • PR #258353 — bulk-get alert actions for per-row status (verify still used after #260195 refactors).
+ • PR #258643 — remove `untag` from docs; tags via `tag` action only.
+ • PR #260218 — rule/status filters, column sort, text search, 1000-row cap (no pagination).
+ • PR #260195 — snooze, ack, resolve, tag display; per-action routes.
+ • PR #260942 — episode detail page; list under alerting_v2 / Stack Management (plus Observability links).
+ • PR #261966 — **Edit tags** flyout on list and detail.
+ • PR #262288 — **Tags** filter (OR semantics, options cap 500).
+ • PR #262459 — **Discover** link with rule query and ±15m time window.
+
+ - id: alerting-v2-explore-alerts-discover
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/alerts/query-alerts-and-signals-in-discover.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/254901
+ - https://github.com/elastic/kibana/pull/258651
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/
+ - x-pack/platform/plugins/shared/alerting/public/
+ doc_set:
+ serverless: preview
+ notes: >
+ How to query alerting data in Discover. References alerting index/view names — must
+ use final values from PR #258651: `.rule-events`, `.alert-actions`, `$.alert-episodes`,
+ `$.rule-events`. The current draft uses older names and needs updating.
+
+ - id: alerting-v2-investigate-respond
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/alerts/view-manage-and-reference-alerts.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/258353
+ - https://github.com/elastic/kibana/pull/258643
+ - https://github.com/elastic/kibana/pull/260195
+ - https://github.com/elastic/kibana/pull/260942
+ - https://github.com/elastic/kibana/pull/261966
+ - https://github.com/elastic/kibana/pull/262459
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/public/pages/alerts/
+ - x-pack/platform/plugins/shared/alerting/server/routes/alerts/
+ doc_set:
+ serverless: preview
+ notes: >
+ Episode detail page and alert actions (`.alert-actions`, scope tables, action types).
+ Consolidated from former alert-episode-details and alert-actions pages. Tracks PRs #260195
+ (table actions), #260942 (detail page), #261966 (edit tags), #262459 (Discover).
+
+ - id: alerting-v2-alert-actions
+ content_type: reference
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/alerts/alert-states-and-fields-reference.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/258353
+ - https://github.com/elastic/kibana/pull/258643
+ - https://github.com/elastic/kibana/pull/256527
+ - https://github.com/elastic/kibana/pull/254901
+ - https://github.com/elastic/kibana/pull/258651
+ - https://github.com/elastic/kibana/pull/260195
+ - https://github.com/elastic/kibana/pull/261966
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/routes/alerts/bulk_get_alert_actions.ts
+ - x-pack/platform/plugins/shared/alerting/server/dispatcher/steps/store_actions_step.ts
+ - x-pack/platform/plugins/shared/alerting/common/alerts/
+ doc_set:
+ serverless: preview
+ notes: >
+ Reference page for all alert actions and the `.alerts-actions` index schema.
+ This page needs four distinct updates:
+ • PR #258643 — remove `untag` from the action type table and the "Available actions"
+ section; tags are managed only via the `tag` action type.
+ • PR #256527 — add `action_type: unmatched` with reason `no matching notification policy`
+ to the "Alert actions fields" table; the current page omits this type.
+ • PR #258651 — update index name throughout: `.alerts-actions` → `.alert-actions`
+ (final name after second rename). Also update any ESQL view references.
+ • PR #258353 — the bulk-get API (`_bulk_get`) is described implicitly here; verify
+ accuracy of the API reference once the route stabilises.
+ • PR #260195 — per-action-type create routes used by the episodes table; UI labels (e.g. Resolve).
+ • PR #261966 — users can add tags from the UI (not only API).
+
+ - id: alerting-v2-episode-details
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/alerts/view-manage-and-reference-alerts.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/258353
+ - https://github.com/elastic/kibana/pull/257347
+ - https://github.com/elastic/kibana/pull/260195
+ - https://github.com/elastic/kibana/pull/260942
+ - https://github.com/elastic/kibana/pull/261966
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/public/pages/alerts/
+ - x-pack/platform/plugins/shared/alerting_v2/public/pages/
+ - packages/kbn-alerting-v2-episodes-ui/
+ - x-pack/platform/plugins/shared/alerting/server/routes/alerts/bulk_get_alert_actions.ts
+ doc_set:
+ serverless: preview
+ notes: >
+ Alert episode detail page (and any legacy flyout references).
+ • PR #260942 — full detail page: heatmap, related episodes, grouping, shared action bar.
+ • PR #260195 — acknowledge, snooze, resolve, etc. on the detail page (parity with list).
+ • PR #261966 — **Edit tags** flyout from the detail page.
+ • PR #258353 — bulk-get alert actions for status display.
+ • PR #257347 — duration in the episode view.
+
+ # ---------------------------------------------------------------------------
+ # {{alerting-v2}} — manage rules
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-manage-rules
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/rules/view-manage-rules.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/256260
+ - https://github.com/elastic/kibana/pull/256692
+ - https://github.com/elastic/kibana/pull/258341
+ - https://github.com/elastic/kibana/pull/260233
+ - https://github.com/elastic/kibana/pull/260270
+ - https://github.com/elastic/kibana/pull/261442
+ - https://github.com/elastic/kibana/pull/260355
+ - https://github.com/elastic/kibana/pull/260798
+ - https://github.com/elastic/rna-program/issues/115
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/public/pages/rules/
+ - x-pack/platform/plugins/shared/alerting/server/rules_client/
+ - x-pack/platform/plugins/shared/alerting_v2/public/pages/
+ doc_set:
+ serverless: preview
+ notes: >
+ How-to content for the rule management UI: view, edit, clone, enable/disable,
+ delete, bulk operations, and the rule details experience. Navigation and labels
+ also depend on PRs #260355 / #260798 (V2 Alerting Preview entry points).
+ • PR #256260 — foundational rules list and create/edit flows (table, pagination,
+ delete).
+ • PR #256692 — rule details page: rule name, kind badge (Detect/Alert),
+ enabled/disabled state, tags, ES|QL base query, alert conditions, actions menu.
+ manage-rules.md should describe navigation to this page and what is visible.
+ • PR #258341 — bulk enable, disable, and delete from the rules list with select-all.
+ • PR #260233 — list filters (status, mode, tags), search, sorting, and tag facet API.
+ • PR #260270 — Conditions | Runbook tabs on the rule details page (runbook markdown).
+ • PR #261442 — bulk ops: 10k cap for filter-based bulk actions; select-all respects
+ active filters and search; UI disclosure when truncated.
+ • PRs #260355 / #260798 — align docs with Management URLs and solution nav for v2.
+ • rna-program#115 — program-level scope (verify against issue when accessible).
+
+ # ---------------------------------------------------------------------------
+ # {{alerting-v2}} — reduce noise
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-reduce-noise
+ content_type: conceptual
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/troubleshooting-alerting-v2.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/255734
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/rules/
+ - x-pack/platform/plugins/shared/alerting/server/dispatcher/
+ doc_set:
+ serverless: preview
+ notes: >
+ Decision-table hub linking to rule settings, action policies, and manage-alerts.
+ Detail pages live under those sections. Index names: `.rule-events`, `.alert-actions`
+ (see chain note at top of file).
+
+ - id: alerting-v2-deactivate-alerts
+ content_type: procedural
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/alerts/view-manage-and-reference-alerts.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/256527
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/server/dispatcher/steps/store_actions_step.ts
+ - x-pack/platform/plugins/shared/alerting/common/alerts/
+ doc_set:
+ serverless: preview
+ notes: >
+ Deactivate/reactivate behavior is documented under Alert actions. PR #256527 changes dispatcher
+ behavior: episodes that are deactivated and also unmatched by any policy now receive
+ an `unmatched` action record in addition to the deactivation.
+
+ # ---------------------------------------------------------------------------
+ # {{alerting-v2}} — alert event field reference
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-event-field-ref
+ content_type: reference
+ docs_file: explore-analyze/alerting/kibana-alerting-v2/rules/rule-event-field-reference.md
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/247464
+ - https://github.com/elastic/kibana/pull/257347
+ - https://github.com/elastic/kibana/pull/256527
+ - https://github.com/elastic/kibana/pull/254901
+ - https://github.com/elastic/kibana/pull/258651
+ watch_paths:
+ - x-pack/platform/plugins/shared/alerting/common/alert_event/
+ - x-pack/platform/plugins/shared/alerting/server/data_streams/
+ doc_set:
+ serverless: preview
+ notes: >
+ Field reference for alert event documents and the alert actions index schema.
+ High-priority page — several PRs require updates:
+ • PR #258651 (final rename) — update ALL index and view name references:
+ `.alerts-events-*` → `.rule-events`
+ `.alerts-actions` → `.alert-actions`
+ `$.alerting-episodes` → `$.alert-episodes`
+ The page description, body text, and index mapping section all use old names.
+ • PR #256527 — add `action_type: unmatched` with reason
+ `no matching notification policy` to the "Alert actions fields" table.
+ • PR #257347 — verify whether a duration field is added to the alert event document
+ schema (the PR adds duration to the episodes view query, not necessarily the raw event).
+ This page should be reviewed before every preview release cycle.
+
+ # ---------------------------------------------------------------------------
+ # Features without doc pages yet (implementation has shipped, docs are gaps)
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-v2-o11y-episodes
+ content_type: procedural
+ docs_file: TBD # No page exists yet
+ docs_pr: ~
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/257638
+ - https://github.com/elastic/kibana/pull/258353
+ - https://github.com/elastic/kibana/pull/257347
+ - https://github.com/elastic/kibana/pull/260218
+ - https://github.com/elastic/kibana/pull/260195
+ - https://github.com/elastic/kibana/pull/260942
+ - https://github.com/elastic/kibana/pull/261966
+ - https://github.com/elastic/kibana/pull/262288
+ - https://github.com/elastic/kibana/pull/262459
+ watch_paths:
+ - packages/kbn-alerting-v2-episodes-ui/
+ - x-pack/solutions/observability/plugins/observability/public/pages/alerts_v2/
+ - x-pack/platform/plugins/shared/alerting_v2/public/pages/
+ doc_set:
+ serverless: preview
+ notes: >
+ Observability and Stack Management surfaces for **Alert episodes** (list + detail).
+ PR #257638 added the initial Observability route; PR #260942 moves primary list/detail into
+ `alerting_v2` under Stack Management while Observability may retain navigation links.
+ Later PRs: #260218 filters/sort/search, #260195 row actions, #261966 edit tags, #262288 tag filter,
+ #262459 Discover link, #258353/#257347 status and duration data. No dedicated observability doc
+ page yet — coordinate with Observability + ResponseOps docs on IA (`manage-alerts.md` may absorb some scope).
+
+ - id: alerting-v2-rule-execution-history
+ content_type: reference
+ docs_file: TBD # No page exists yet
+ docs_pr: ~
+ implementation_prs:
+ - https://github.com/elastic/kibana/pull/254990
+ watch_paths:
+ - x-pack/platform/plugins/shared/task_manager/server/task_events.ts
+ doc_set:
+ serverless: preview
+ notes: >
+ PR #254990 adds event log entries to Task Manager for rule execution outcomes
+ (success, failure, cancelled) in `.kibana-event-log*`. This enables a rule
+ execution history view. No doc page exists yet — determine if this should live
+ under manage-rules/ or be a standalone reference page. Coordinate with the
+ ResponseOps team on planned UI surface before writing the doc.
+
+ # ---------------------------------------------------------------------------
+ # Watcher (existing, reorganized under alerting IA)
+ # ---------------------------------------------------------------------------
+
+ - id: alerting-watcher
+ content_type: reference
+ docs_file: explore-analyze/alerting/watcher/
+ docs_pr: https://github.com/elastic/docs-content/pull/5528
+ implementation_prs: []
+ watch_paths:
+ - x-pack/plugin/watcher/
+ doc_set:
+ stack: ga
+ notes: >
+ Existing Watcher docs (watcher.md and enable-watcher.md), now surfaced under
+ the alerting IA alongside v1 and v2. Content stable. Review only if Watcher
+ receives significant changes, which is unlikely given its maintenance-mode status.
diff --git a/docset.yml b/docset.yml
index 5ecf676ed5..287a0a359f 100644
--- a/docset.yml
+++ b/docset.yml
@@ -111,7 +111,6 @@ subs:
dev-tools-app: "Dev Tools"
stack-manage-app: "Stack Management"
stack-monitor-app: "Stack Monitoring"
- rules-ui: "Rules"
connectors-ui: "Connectors"
connectors-feature: "Actions and Connectors"
stack-rules-feature: "Stack Rules"
@@ -299,3 +298,7 @@ subs:
fedramp-mod: "FedRAMP Moderate"
fedramp-high: "FedRAMP High"
fedramp-il5: "FedRAMP IL5"
+ alerting-v2: "Kibana alerting v2"
+ rules-ui: "Rules"
+ rules-ui-v2: "Rules"
+ alerts-ui: "Alert episodes"
diff --git a/explore-analyze/alerting-overview.md b/explore-analyze/alerting-overview.md
new file mode 100644
index 0000000000..77c2c21dcc
--- /dev/null
+++ b/explore-analyze/alerting-overview.md
@@ -0,0 +1,62 @@
+---
+mapped_pages:
+ - https://www.elastic.co/guide/en/kibana/current/alerting-getting-started.html#alerting-concepts-differences
+ - https://www.elastic.co/guide/en/serverless/current/project-settings-alerts.html
+applies_to:
+ stack: ga
+ serverless: ga
+products:
+ - id: kibana
+ - id: cloud-serverless
+ - id: elasticsearch
+ - id: cloud-hosted
+navigation_title: Alerting
+description: "Elastic alerting overview: Kibana v1, v2 (ES|QL, action policies, alert history), and Watcher; where each runs and how to get started."
+---
+
+# Alerting [alerting-overview]
+
+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, summarized below. Each has a **Get started** link to the full guide for that option.
+
+## Kibana alerting v1
+
+```{applies_to}
+stack: ga
+serverless: ga
+```
+
+Kibana alerting v1 gives you ready-made rule types that work with applications such as APM, metrics, security, and uptime monitoring. You set conditions on a schedule you choose and send notifications through common channels (email, chat apps, webhooks, on-call tools, and more). Setup uses forms and clear steps, so you do not need to learn a query language first. It is a strong fit when you want broad coverage out of the box.
+
+[Get started with Kibana alerting v1 →](alerting/kibana-alerting-v1.md)
+
+## {{alerting-v2}}
+
+```{applies_to}
+serverless: preview
+stack: unavailable
+```
+
+{{alerting-v2}} is built on {{esql}}. You write the query that defines what to watch for, choose how alerts are tracked per series, and control notifications through action policies (shared objects that handle routing, frequency, and notification batching across many rules at once). It adds alert lifecycle tracking with episodes, per-series snooze, and rules on alerts for correlation and escalation. {{alerting-v2}} a strong fit when you want full control over what data travels with each alert and how your team is notified.
+
+[Get started with {{alerting-v2}} →](alerting/kibana-alerting-v2.md)
+
+:::{note}
+{{alerting-v2}} runs next to Kibana alerting v1 on supported deployments. You do not have to move everything at once. Teams can copy or rebuild rules when they are ready. Kibana alerting v1 will remain available.
+:::
+
+## Watcher
+
+```{applies_to}
+stack: ga
+serverless: unavailable
+```
+
+Watcher is for unusual or highly tailored setups where you need scripts, chained steps, or close control over {{es}} APIs. It does not use the main {{kib}} rules UI used by {{kib}} alerting. It is available on the {{stack}} only, not in {{serverless-full}}.
+
+:::{tip}
+For most teams, Kibana alerting v1 or v2 is easier to adopt: they include more ready-made building blocks and a single place in {{kib}} to work with rules.
+:::
+
+[Get started with Watcher →](alerting/watcher.md)
diff --git a/explore-analyze/alerting.md b/explore-analyze/alerting.md
deleted file mode 100644
index b0aa40b604..0000000000
--- a/explore-analyze/alerting.md
+++ /dev/null
@@ -1,35 +0,0 @@
----
-mapped_pages:
- - https://www.elastic.co/guide/en/kibana/current/alerting-getting-started.html#alerting-concepts-differences
- - https://www.elastic.co/guide/en/serverless/current/project-settings-alerts.html
-applies_to:
- stack: ga
- serverless: ga
-products:
- - id: kibana
- - id: cloud-serverless
----
-
-# Alerting
-
-Alerting tools in Elasticsearch and Kibana provide functionality to monitor data and notify you about significant changes or events in real time. This page provides an overview of how the key components work.
-
-## Alerts
-
-Alerts are notifications generated when specific conditions are met. These notifications are sent to you through channels that you previously set such as email, Slack, webhooks, PagerDuty, and so on.
-
-Alerts are created based on rules, which define the criteria for triggering them. Rules monitor the data indexed in Elasticsearch and evaluate conditions on a defined schedule to identify matches. For example, a threshold rule can generate an alert when a value crosses a specific threshold, while a machine learning rule activates an alert when an anomaly detection job identifies an anomaly.
-
-## Watcher
-```{applies_to}
-serverless: unavailable
-```
-
-You can use Watcher for alerting and monitoring specific conditions in your data. It enables you to define rules and take automated actions when certain criteria are met. Watcher is a powerful alerting tool for custom use cases and more complex alerting logic. It allows advanced scripting using Painless to define complex conditions and transformations.
-
-:::{tip}
-For most use cases, you should use Kibana Alerts instead of Watcher. Kibana Alerts allows rich integrations across use cases like APM, metrics, security, and uptime. Prepackaged rule types simplify setup and hide the details of complex, domain-specific detections, while providing a consistent interface across Kibana.
-
-Watcher is not available in {{serverless-full}}.
-:::
-
diff --git a/explore-analyze/alerting/choose-an-alerting-system.md b/explore-analyze/alerting/choose-an-alerting-system.md
new file mode 100644
index 0000000000..d5ceb98b0e
--- /dev/null
+++ b/explore-analyze/alerting/choose-an-alerting-system.md
@@ -0,0 +1,37 @@
+---
+applies_to:
+ stack: ga
+ serverless: ga
+products:
+ - id: kibana
+ - id: cloud-serverless
+ - id: elasticsearch
+ - id: cloud-hosted
+description: Short guide to select Kibana alerting v1, v2, or Watcher by use case, deployment, and how much control you need, with links to detailed docs.
+---
+
+# Choose an alerting system [choose-an-alerting-system]
+
+Elastic has three alerting systems. You only need one. Pick the one that fits how you want to define rules and route notifications.
+
+## Select by use case
+
+| Goal | Suggested system | Availability |
+|---|---|---|
+| Monitor metrics, logs, or uptime with ready-made rules and no query language | [Kibana alerting v1](kibana-alerting-v1.md) | All deployments |
+| Use rules built for Security, Observability, APM, or Maps | [Kibana alerting v1](kibana-alerting-v1.md) | All deployments |
+| Write {{esql}} to define exactly what to detect and what data each alert carries | [{{alerting-v2}}](kibana-alerting-v2.md) | {{serverless-full}} |
+| Query alert history in Discover or build dashboards from alert data | [{{alerting-v2}}](kibana-alerting-v2.md) | {{serverless-full}} |
+| Manage notification routing, grouping, and throttling in one place, reusable across rules | [{{alerting-v2}}](kibana-alerting-v2.md) | {{serverless-full}} |
+| Build highly custom logic with scripting and chained inputs | [Watcher](watcher.md) | Self-managed and {{ech}} only |
+
+## Compare at a glance
+
+| | Kibana alerting v1 | {{alerting-v2}} | Watcher |
+|---|---|---|---|
+| **Best for** | Teams using built-in rule types with form-based setup | Teams that need full control over detection and notification routing | Custom alerting logic requiring scripting |
+| **Rule definition** | Select a rule type and fill in parameters | Write an {{esql}} query | Write a JSON watch definition |
+| **Alert data** | Updated in place; limited query support | Append-only events queryable with {{esql}} in Discover | Watch history index |
+| **Notifications** | Configured per action on each rule | Centralized action policies, reusable across rules | Action-level throttling and conditions |
+| **Noise reduction** | Snooze per rule, maintenance windows | Per-series snooze, per-episode acknowledgment, activation thresholds, matcher-based routing, rules on alerts | Action conditions and throttling |
+| **Availability** | All deployments | {{serverless-full}} | Self-managed and {{ech}} only |
diff --git a/explore-analyze/alerting/alerts.md b/explore-analyze/alerting/kibana-alerting-v1.md
similarity index 90%
rename from explore-analyze/alerting/alerts.md
rename to explore-analyze/alerting/kibana-alerting-v1.md
index ccd9c103f0..736907a044 100644
--- a/explore-analyze/alerting/alerts.md
+++ b/explore-analyze/alerting/kibana-alerting-v1.md
@@ -10,9 +10,10 @@ products:
- id: kibana
- id: cloud-serverless
- id: cloud-hosted
+description: "Overview of Kibana alerting v1 — define rules with conditions, schedules, and actions to detect issues and send notifications through built-in connectors."
---
-# Alerts
+# Kibana alerting v1 [alerting-overview-v1]
## {{rules-ui}} [rules]
@@ -83,7 +84,7 @@ If you are not using alert summaries, actions are triggered per alert and a rule
* Minute 2: X123 and Y456 > 0.9. *Two emails* are sent, one for X123 and one for Y456.
* Minute 3: X123, Y456, Z789 > 0.9. *Three emails* are sent, one for each of X123, Y456, Z789.
-In this example, three emails are sent for server X123 in the span of 3 minutes for the same rule. Often, it’s desirable to suppress these re-notifications. If you set the action frequency to `On custom action intervals` with an interval of 5 minutes, you reduce noise by getting emails only every 5 minutes for servers that continue to exceed the threshold:
+In this example, three emails are sent for server X123 in the span of 3 minutes for the same rule. Often, it's desirable to suppress these re-notifications. If you set the action frequency to `On custom action intervals` with an interval of 5 minutes, you reduce noise by getting emails only every 5 minutes for servers that continue to exceed the threshold:
* Minute 1: server X123 > 0.9. *One email* will be sent for server X123.
* Minute 2: X123 and Y456 > 0.9. *One email* will be sent for Y456.
@@ -102,7 +103,7 @@ You can pass rule values to an action at the time a condition is detected. To vi
:screenshot:
:::
-For more information about common action variables, refer to [Rule actions variables](alerts/rule-action-variables.md)
+For more information about common action variables, refer to [Rule action variables](kibana-alerting-v1/rule-action-variables-v1.md)
### Alerts [rules-alerts]
@@ -119,7 +120,7 @@ A rule consists of conditions, actions, and a schedule. When conditions are met,
:screenshot:
:::
-1. Any time a rule’s conditions are met, an alert is created. This example checks for servers with average CPU > 0.9. Three servers meet the condition, so three alerts are created.
+1. Any time a rule's conditions are met, an alert is created. This example checks for servers with average CPU > 0.9. Three servers meet the condition, so three alerts are created.
2. Alerts create actions according to the action frequency, as long as they are not muted or throttled. When actions are created, its properties are filled with actual values. In this example, three actions are created when the threshold is met, and the template string `{{server}}` is replaced with the appropriate server name for each alert.
3. {{kib}} runs the actions, sending notifications by using a third party integration like an email service.
4. If the third party integration has connection parameters or credentials, {{kib}} fetches these from the appropriate connector.
diff --git a/explore-analyze/alerting/alerts/alerting-common-issues.md b/explore-analyze/alerting/kibana-alerting-v1/alerting-common-issues-v1.md
similarity index 91%
rename from explore-analyze/alerting/alerts/alerting-common-issues.md
rename to explore-analyze/alerting/kibana-alerting-v1/alerting-common-issues-v1.md
index 95abc28c8c..f6993457e8 100644
--- a/explore-analyze/alerting/alerts/alerting-common-issues.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/alerting-common-issues-v1.md
@@ -39,7 +39,7 @@ Actions run long after the status of a rule changes, sending a notification of t
Rules and actions run as background tasks by each {{kib}} instance at a default rate of ten tasks every three seconds. When diagnosing issues related to alerting, focus on the tasks that begin with `alerting:` and `actions:`.
-Alerting tasks always begin with `alerting:`. For example, the `alerting:.index-threshold` tasks back the [index threshold stack rule](rule-type-index-threshold.md). Action tasks always begin with `actions:`. For example, the `actions:.index` tasks back the [index action](kibana://reference/connectors-kibana/index-action-type.md).
+Alerting tasks always begin with `alerting:`. For example, the `alerting:.index-threshold` tasks back the [index threshold stack rule](rule-type-index-threshold-v1.md). Action tasks always begin with `actions:`. For example, the `actions:.index` tasks back the [index action](kibana://reference/connectors-kibana/index-action-type.md).
For more details on monitoring and diagnosing tasks in Task Manager, refer to [Health monitoring](../../../deploy-manage/monitor/kibana-task-manager-health-monitoring.md).
@@ -72,7 +72,7 @@ By default, rules have a `5m` timeout. Rules that run longer than this timeout a
[2022-03-28T13:14:04.062-04:00][WARN ][plugins.taskManager] Cancelling task alerting:.index-threshold "a6ea0070-aec0-11ec-9985-dd576a3fe205" as it expired at 2022-03-28T17:14:03.980Z after running for 05m 10s (with timeout set at 5m).
```
-and in the [details page](create-manage-rules.md#rule-details):
+and in the [details page](create-manage-rules-v1.md#rule-details):
:::{image} /explore-analyze/images/kibana-rule-details-timeout-error.png
:alt: Rule details page with timeout error
@@ -81,7 +81,7 @@ and in the [details page](create-manage-rules.md#rule-details):
If you want your rules to run longer, update the `xpack.alerting.rules.run.timeout` configuration in your [Alerting settings](kibana://reference/configuration-reference/alerting-settings.md#alert-settings). You can also target a specific rule type by using `xpack.alerting.rules.run.ruleTypeOverrides`.
-Rules that consistently run longer than their [check interval](create-manage-rules.md#create-edit-rules) may produce unexpected results. If the average run duration, visible on the [details page](create-manage-rules.md#rule-details), is greater than the check interval, consider increasing the check interval.
+Rules that consistently run longer than their [check interval](create-manage-rules-v1.md#create-edit-rules) may produce unexpected results. If the average run duration, visible on the [details page](create-manage-rules-v1.md#rule-details), is greater than the check interval, consider increasing the check interval.
To get all long-running rules, you can query for a list of rule ids, bucketed by their run times:
@@ -248,7 +248,7 @@ This error happens when the `xpack.encryptedSavedObjects.encryptionKey` value us
| --- | --- |
| If the value in `xpack.encryptedSavedObjects.encryptionKey` was manually changed, and the previous encryption key is still known. | Ensure any previous encryption key is included in the keys used for [decryption only](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-keyrotation-decryptiononlykeys). |
| If another {{kib}} instance with a different encryption key connects to the cluster. | The other {{kib}} instance might be trying to run the rule using a different encryption key than what the rule was created with. Ensure the encryption keys among all the {{kib}} instances are the same, and setting [decryption only keys](kibana://reference/configuration-reference/security-settings.md#xpack-encryptedsavedobjects-keyrotation-decryptiononlykeys) for previously used encryption keys. |
-| If other scenarios don’t apply. | Generate a new API key for the rule. For example, in **{{stack-manage-app}} > {{rules-ui}}**, select **Update API key** from the action menu. |
+| If other scenarios don’t apply. | Generate a new API key for the rule. For example, in **{{stack-manage-app}} > {{rules-ui-v2}}**, select **Update API key** from the action menu. |
## Rules stop running after upgrade [known-issue-upgrade-rule]
@@ -262,4 +262,4 @@ Alerting rules that were created or edited in 8.2 stop running after you upgrade
**Solution**:
-Upgrade to 8.3.2 or later releases to avoid the problem. To fix failing rules, go to **{{stack-manage-app}} > {{rules-ui}}** and multi-select the rules. Choose **Manage rules > Update API Keys** to generate new API keys. For more details about API key authorization, refer to [API keys](alerting-setup.md#alerting-authorization).
+Upgrade to 8.3.2 or later releases to avoid the problem. To fix failing rules, go to **{{stack-manage-app}} > {{rules-ui-v2}}** and multi-select the rules. Choose **Manage rules > Update API Keys** to generate new API keys. For more details about API key authorization, refer to [API keys](alerting-setup-v1.md#alerting-authorization).
diff --git a/explore-analyze/alerting/alerts/alerting-getting-started.md b/explore-analyze/alerting/kibana-alerting-v1/alerting-getting-started-v1.md
similarity index 92%
rename from explore-analyze/alerting/alerts/alerting-getting-started.md
rename to explore-analyze/alerting/kibana-alerting-v1/alerting-getting-started-v1.md
index ba1b7394e7..70248b29d7 100644
--- a/explore-analyze/alerting/alerts/alerting-getting-started.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/alerting-getting-started-v1.md
@@ -16,14 +16,14 @@ products:
# Getting started with alerting [alerting-getting-started]
-Alerting enables you to define *rules*, which detect complex conditions within different {{kib}} apps and trigger actions when those conditions are met. Alerting is integrated with [**{{observability}}**](../../../solutions/observability/incident-management/alerting.md), [**Security**](detection-rules://index.md), [**Maps**](geo-alerting.md) and [**{{ml-app}}**](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md). It can be centrally managed from **{{stack-manage-app}}** and provides a set of built-in [connectors](../../../deploy-manage/manage-connectors.md) and [rules](rule-types.md#stack-rules) for you to use.
+Alerting enables you to define *rules*, which detect complex conditions within different {{kib}} apps and trigger actions when those conditions are met. Alerting is integrated with [**{{observability}}**](../../../solutions/observability/incident-management/alerting.md), [**Security**](detection-rules://index.md), [**Maps**](geo-alerting-v1.md) and [**{{ml-app}}**](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md). It can be centrally managed from **{{stack-manage-app}}** and provides a set of built-in [connectors](../../../deploy-manage/manage-connectors.md) and [rules](rule-types-v1.md#stack-rules) for you to use.
:::{image} /explore-analyze/images/kibana-alerting-overview.png
-:alt: {{rules-ui}} UI
+:alt: Rules UI
:::
::::{important}
-To make sure you can access alerting and actions, see the [setup and prerequisites](alerting-setup.md#alerting-prerequisites) section.
+To make sure you can access alerting and actions, see the [setup and prerequisites](alerting-setup-v1.md#alerting-prerequisites) section.
::::
@@ -31,7 +31,7 @@ Alerting works by running checks on a schedule to detect conditions defined by a
## Rules [_rules]
-A rule specifies a background task that runs on the {{kib}} server to check for specific conditions. {{kib}} provides two types of rules: stack rules that are built into {{kib}} and the rules that are registered by {{kib}} apps. For more information, refer to [*Rule types*](rule-types.md).
+A rule specifies a background task that runs on the {{kib}} server to check for specific conditions. {{kib}} provides two types of rules: stack rules that are built into {{kib}} and the rules that are registered by {{kib}} apps. For more information, refer to [*Rule types*](rule-types-v1.md).
A rule consists of three main parts:
@@ -57,9 +57,9 @@ Under the hood, {{kib}} rules detect conditions by running a JavaScript function
These conditions are packaged and exposed as *rule types*. A rule type hides the underlying details of the condition, and exposes a set of parameters to control the details of the conditions to detect.
-For example, an [index threshold rule type](rule-type-index-threshold.md) lets you specify the index to query, an aggregation field, and a time window, but the details of the underlying {{es}} query are hidden.
+For example, an [index threshold rule type](rule-type-index-threshold-v1.md) lets you specify the index to query, an aggregation field, and a time window, but the details of the underlying {{es}} query are hidden.
-See [*Rule types*](rule-types.md) for the rules provided by {{kib}} and how they express their conditions.
+See [*Rule types*](rule-types-v1.md) for the rules provided by {{kib}} and how they express their conditions.
### Schedule [alerting-concepts-scheduling]
diff --git a/explore-analyze/alerting/alerts/alerting-setup.md b/explore-analyze/alerting/kibana-alerting-v1/alerting-setup-v1.md
similarity index 100%
rename from explore-analyze/alerting/alerts/alerting-setup.md
rename to explore-analyze/alerting/kibana-alerting-v1/alerting-setup-v1.md
diff --git a/explore-analyze/alerting/alerts/alerting-troubleshooting.md b/explore-analyze/alerting/kibana-alerting-v1/alerting-troubleshooting-v1.md
similarity index 93%
rename from explore-analyze/alerting/alerts/alerting-troubleshooting.md
rename to explore-analyze/alerting/kibana-alerting-v1/alerting-troubleshooting-v1.md
index fdb5a36e1b..229d73f17d 100644
--- a/explore-analyze/alerting/alerts/alerting-troubleshooting.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/alerting-troubleshooting-v1.md
@@ -27,12 +27,12 @@ Some of the resources, such as saved objects and API keys, may no longer be avai
The following debugging tools are available:
-* {{kib}} versions 7.10 and above have a [Test connector](testing-connectors.md) UI.
+* {{kib}} versions 7.10 and above have a [Test connector](testing-connectors-v1.md) UI.
* {{kib}} versions 7.11 and above include improved Webhook error messages, better overall debug logging for actions and connectors, and Task Manager [diagnostics endpoints](../../../troubleshoot/kibana/task-manager.md#task-manager-diagnosing-root-cause).
## Using rules and connectors list for the current state and finding issues [alerting-managment-detail]
-**{{rules-ui}}** in **{{stack-manage-app}}** lists the rules available in the space you’re currently in. When you click a rule name, you are navigated to the [details page](create-manage-rules.md#rule-details) for the rule, where you can see currently active alerts. The start date on this page indicates when a rule is triggered, and for what alerts. In addition, the duration of the condition indicates how long the instance is active.
+**{{rules-ui}}** in **{{stack-manage-app}}** lists the rules available in the space you’re currently in. When you click a rule name, you are navigated to the [details page](create-manage-rules-v1.md#rule-details) for the rule, where you can see currently active alerts. The start date on this page indicates when a rule is triggered, and for what alerts. In addition, the duration of the condition indicates how long the instance is active.
:::{image} /explore-analyze/images/kibana-rule-details-alerts-inactive.png
:alt: Alerting management details
@@ -180,9 +180,9 @@ Investigating the underlying task can help you gauge whether the problem you’r
In addition to the above methods, refer to the following approaches and common issues:
-* [Alerting common issues](alerting-common-issues.md)
-* [Querying event log index](event-log-index.md)
-* [Testing connectors using {{connectors-ui}} UI and the `kbn-action` tool](testing-connectors.md)
+* [Alerting common issues](alerting-common-issues-v1.md)
+* [Querying event log index](event-log-index-v1.md)
+* [Testing connectors using {{connectors-ui}} UI and the `kbn-action` tool](testing-connectors-v1.md)
### Temporarily throttle all tasks [alerting-kibana-throttle]
@@ -194,7 +194,7 @@ xpack.task_manager.poll_interval: 1h
```
::::{warning}
-This approach should be used only temporarily as a last resort to restore function to {{kib}} when it is unresponsive and attempts to identify and [snooze or disable](create-manage-rules.md#controlling-rules) slow-running rules have not fixed the situation. It severely throttles all background tasks, not just those relating to {{alert-features}}. The task manager will run only one task at a time and will look for more work each hour.
+This approach should be used only temporarily as a last resort to restore function to {{kib}} when it is unresponsive and attempts to identify and [snooze or disable](create-manage-rules-v1.md#controlling-rules) slow-running rules have not fixed the situation. It severely throttles all background tasks, not just those relating to {{alert-features}}. The task manager will run only one task at a time and will look for more work each hour.
::::
diff --git a/explore-analyze/alerting/alerts/create-manage-rules.md b/explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md
similarity index 94%
rename from explore-analyze/alerting/alerts/create-manage-rules.md
rename to explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md
index 4dbf5c249b..e198dc54d4 100644
--- a/explore-analyze/alerting/alerts/create-manage-rules.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md
@@ -11,7 +11,7 @@ products:
# Create and manage alerting rules with {{kib}} [create-and-manage-rules]
-The **{{stack-manage-app}}** > **{{rules-ui}}** UI provides a cross-app view of alerting. Different {{kib}} apps like [**{{observability}}**](../../../solutions/observability/incident-management/alerting.md), [**Security**](detection-rules://index.md), [**Maps**](geo-alerting.md) and [**{{ml-app}}**](../../machine-learning/machine-learning-in-kibana.md) can offer their own rules.
+The **{{stack-manage-app}}** > **{{rules-ui}}** UI provides a cross-app view of alerting. Different {{kib}} apps like [**{{observability}}**](../../../solutions/observability/incident-management/alerting.md), [**Security**](detection-rules://index.md), [**Maps**](geo-alerting-v1.md) and [**{{ml-app}}**](../../machine-learning/machine-learning-in-kibana.md) can offer their own rules.
You can find **Rules** in **Stack Management** > **Alerts and insights** > **Rules** in {{kib}} or by using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md).
@@ -31,7 +31,7 @@ All of your alerting rules appear in one list on the **Rules** page. Open the pa
* Drill down to [rule details](#rule-details)
* Configure rule settings
-For more information on alerting concepts and the types of rules and connectors available, go to [Alerting](../alerts.md).
+For more information on alerting concepts and the types of rules and connectors available, go to [Alerting](../kibana-alerting-v1.md).
:::{agent-skill}
:url: https://github.com/elastic/agent-skills/tree/main/skills/kibana/kibana-alerting-rules
@@ -39,7 +39,7 @@ For more information on alerting concepts and the types of rules and connectors
## Required permissions [_required_permissions]
-Access to rules is granted based on your {{alert-features}} privileges. For more information, go to [Security](alerting-setup.md#alerting-security).
+Access to rules is granted based on your {{alert-features}} privileges. For more information, go to [Security](alerting-setup-v1.md#alerting-security).
## {{cps-cap}} scope for rules [cps-scope-for-rules]
```{applies_to}
@@ -80,11 +80,11 @@ Each rule type provides its own way of defining the conditions to detect, but an
All rules must have a check interval, which defines how often to evaluate the rule conditions. Checks are queued; they run as close to the defined value as capacity allows.
-For details on what types of rules are available and how to configure them, refer to [*Rule types*](rule-types.md).
+For details on what types of rules are available and how to configure them, refer to [*Rule types*](rule-types-v1.md).
### Alert flapping [defining-rules-flapping-details]
-You can modify the criteria for changing an alert's status to [`flapping`](view-alerts.md#alert-status) by configuring the **Alert flapping detection** settings, which are turned on by default. When configuring flapping settings, you must set a look back window and threshold for alert status changes. For example, you can specify that alerts with at least 6 status changes in the last 10 runs are `flapping`.
+You can modify the criteria for changing an alert's status to [`flapping`](view-alerts-v1.md#alert-status) by configuring the **Alert flapping detection** settings, which are turned on by default. When configuring flapping settings, you must set a look back window and threshold for alert status changes. For example, you can specify that alerts with at least 6 status changes in the last 10 runs are `flapping`.
{applies_to}`stack: ga 9.3+` You can modify the flapping settings for a specific rule while creating or editing it. You can also modify the flapping settings for all rules in your {{kib}} space or {{serverless-short}} project. To do this, go to the **Rules** page (find the **Rules** management page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md)), click **Settings**, then go to the **Alert flapping detection** settings.
@@ -148,7 +148,7 @@ You can pass rule values to an action at the time a condition is detected. To vi
:screenshot:
:::
-For more information about common action variables, refer to [*Rule action variables*](rule-action-variables.md).
+For more information about common action variables, refer to [*Rule action variables*](rule-action-variables-v1.md).
## Snooze and disable rules [controlling-rules]
@@ -164,7 +164,7 @@ When you snooze a rule, the rule checks continue to run on a schedule but alerts
When a rule is in a snoozed state, you can cancel or change the duration of this state.
-{applies_to}`stack: preview` {applies_to}`serverless: preview` To temporarily suppress notifications for rules, you can also create a [maintenance window](maintenance-windows.md).
+{applies_to}`stack: preview` {applies_to}`serverless: preview` To temporarily suppress notifications for rules, you can also create a [maintenance window](maintenance-windows-v1.md).
## View rule details [rule-details]
@@ -186,7 +186,7 @@ Click the rule name to access a rule details page:
:screenshot:
:::
-In this example, the rule detects when a site serves more than a threshold number of bytes in a 24 hour period. Four sites are above the threshold. These are called alerts - occurrences of the condition being detected - and the alert name, status, time of detection, and duration of the condition are shown in this view. Alerts come and go from the list depending on whether the rule conditions are met. For more information about alerts, go to [*View alerts*](view-alerts.md).
+In this example, the rule detects when a site serves more than a threshold number of bytes in a 24 hour period. Four sites are above the threshold. These are called alerts - occurrences of the condition being detected - and the alert name, status, time of detection, and duration of the condition are shown in this view. Alerts come and go from the list depending on whether the rule conditions are met. For more information about alerts, go to [*View alerts*](view-alerts-v1.md).
If there are rule actions that failed to run successfully, you can see the details on the **History** tab. In the **Message** column, click the warning or expand icon  or click the number in the **Errored actions** column to open the **Errored Actions** panel. In this example, the action failed because the [`xpack.actions.email.domain_allowlist`](kibana://reference/configuration-reference/alerting-settings.md#action-config-email-domain-allowlist) setting was updated and the action’s email recipient is no longer included in the allowlist:
diff --git a/explore-analyze/alerting/alerts/event-log-index.md b/explore-analyze/alerting/kibana-alerting-v1/event-log-index-v1.md
similarity index 100%
rename from explore-analyze/alerting/alerts/event-log-index.md
rename to explore-analyze/alerting/kibana-alerting-v1/event-log-index-v1.md
diff --git a/explore-analyze/alerting/alerts/geo-alerting.md b/explore-analyze/alerting/kibana-alerting-v1/geo-alerting-v1.md
similarity index 99%
rename from explore-analyze/alerting/alerts/geo-alerting.md
rename to explore-analyze/alerting/kibana-alerting-v1/geo-alerting-v1.md
index 51b580363b..7b90e6350c 100644
--- a/explore-analyze/alerting/alerts/geo-alerting.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/geo-alerting-v1.md
@@ -59,7 +59,7 @@ You can pass rule values to an action to provide contextual details. To view the
:screenshot:
:::
-The following action variables are specific to the tracking containment rule. You can also specify [variables common to all rules](rule-action-variables.md).
+The following action variables are specific to the tracking containment rule. You can also specify [variables common to all rules](rule-action-variables-v1.md).
`context.containingBoundaryId`
: The identifier for the boundary containing the entity. This value is not set for recovered alerts.
diff --git a/explore-analyze/alerting/alerts/maintenance-windows.md b/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md
similarity index 91%
rename from explore-analyze/alerting/alerts/maintenance-windows.md
rename to explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md
index e533d41812..2c5d3e3fb1 100644
--- a/explore-analyze/alerting/alerts/maintenance-windows.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md
@@ -67,7 +67,7 @@ If you turn on **Filter alerts**, you can use KQL to filter the alerts affected
::::{note}
* {applies_to}`stack: removed 9.2` {applies_to}`serverless: removed` You can select only a single category when you turn on filters.
-* Some rules are not affected by maintenance window filters because their alerts do not contain requisite data. In particular, [{{stack-monitor-app}}](../../../deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md), [tracking containment](geo-alerting.md), [{{anomaly-jobs}} health](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md), and [transform health](../../../explore-analyze/transforms/transform-alerts.md) rules are not affected by the filters.
+* Some rules are not affected by maintenance window filters because their alerts do not contain requisite data. In particular, [{{stack-monitor-app}}](../../../deploy-manage/monitor/monitoring-data/configure-stack-monitoring-alerts.md), [tracking containment](geo-alerting-v1.md), [{{anomaly-jobs}} health](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md), and [transform health](../../../explore-analyze/transforms/transform-alerts.md) rules are not affected by the filters.
::::
@@ -78,4 +78,4 @@ A maintenance window can have any one of the following statuses:
* `Finished`: It ended and does not have a repeat schedule.
* `Archived`: It is archived. In a future release, archived maintenance windows will be queued for deletion.
-When you [view alert details](create-manage-rules.md#rule-details) in {{kib}}, each alert shows unique identifiers for maintenance windows that affected it.
+When you [view alert details](create-manage-rules-v1.md#rule-details) in {{kib}}, each alert shows unique identifiers for maintenance windows that affected it.
diff --git a/explore-analyze/alerting/alerts/notifications-domain-allowlist.md b/explore-analyze/alerting/kibana-alerting-v1/notifications-domain-allowlist-v1.md
similarity index 100%
rename from explore-analyze/alerting/alerts/notifications-domain-allowlist.md
rename to explore-analyze/alerting/kibana-alerting-v1/notifications-domain-allowlist-v1.md
diff --git a/explore-analyze/alerting/alerts/query-alerts.md b/explore-analyze/alerting/kibana-alerting-v1/query-alerts-v1.md
similarity index 100%
rename from explore-analyze/alerting/alerts/query-alerts.md
rename to explore-analyze/alerting/kibana-alerting-v1/query-alerts-v1.md
diff --git a/explore-analyze/alerting/alerts/rule-action-variables.md b/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md
similarity index 100%
rename from explore-analyze/alerting/alerts/rule-action-variables.md
rename to explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md
diff --git a/explore-analyze/alerting/alerts/rule-type-es-query.md b/explore-analyze/alerting/kibana-alerting-v1/rule-type-es-query-v1.md
similarity index 98%
rename from explore-analyze/alerting/alerts/rule-type-es-query.md
rename to explore-analyze/alerting/kibana-alerting-v1/rule-type-es-query-v1.md
index 316b774b88..cf94156dbd 100644
--- a/explore-analyze/alerting/alerts/rule-type-es-query.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/rule-type-es-query-v1.md
@@ -154,7 +154,7 @@ Elasticsearch query rule '{{rule.name}}' is active:
- Link: {{context.link}}
```
-Rules use rule action variables and Mustache templates to pass contextual details into the alert notifications. There is a set of [variables common to all rules](create-manage-rules.md#defining-rules-actions-variables) and a set that is specific to this rule. To view the list of variables in {{kib}}, click the "add rule variable" button. For example:
+Rules use rule action variables and Mustache templates to pass contextual details into the alert notifications. There is a set of [variables common to all rules](create-manage-rules-v1.md#defining-rules-actions-variables) and a set that is specific to this rule. To view the list of variables in {{kib}}, click the "add rule variable" button. For example:
:::{image} /explore-analyze/images/kibana-es-query-rule-action-variables.png
:alt: Passing rule values to an action
diff --git a/explore-analyze/alerting/alerts/rule-type-index-threshold.md b/explore-analyze/alerting/kibana-alerting-v1/rule-type-index-threshold-v1.md
similarity index 98%
rename from explore-analyze/alerting/alerts/rule-type-index-threshold.md
rename to explore-analyze/alerting/kibana-alerting-v1/rule-type-index-threshold-v1.md
index 859be8e5ee..872549d16e 100644
--- a/explore-analyze/alerting/alerts/rule-type-index-threshold.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/rule-type-index-threshold-v1.md
@@ -63,7 +63,7 @@ You can further refine the conditions under which actions run by specifying that
## Add action variables [action-variables-index-threshold]
-The following action variables are specific to the index threshold rule. You can also specify [variables common to all rules](rule-action-variables.md).
+The following action variables are specific to the index threshold rule. You can also specify [variables common to all rules](rule-action-variables-v1.md).
`context.conditions`
: A description of the threshold condition. Example: `count greater than 4`
@@ -132,7 +132,7 @@ In this example, you will use the {{kib}} [sample weblog data set](/explore-anal
:screenshot:
:::
- The unique action variables that you can use in the notification are listed in [Add action variables](#action-variables-index-threshold). For more information, refer to [Actions](create-manage-rules.md#defining-rules-actions-details) and [*Connectors*](../../../deploy-manage/manage-connectors.md).
+ The unique action variables that you can use in the notification are listed in [Add action variables](#action-variables-index-threshold). For more information, refer to [Actions](create-manage-rules-v1.md#defining-rules-actions-details) and [*Connectors*](../../../deploy-manage/manage-connectors.md).
9. Save the rule.
diff --git a/explore-analyze/alerting/alerts/rule-types.md b/explore-analyze/alerting/kibana-alerting-v1/rule-types-v1.md
similarity index 57%
rename from explore-analyze/alerting/alerts/rule-types.md
rename to explore-analyze/alerting/kibana-alerting-v1/rule-types-v1.md
index 646c1c493e..e9d6f86b3a 100644
--- a/explore-analyze/alerting/alerts/rule-types.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/rule-types-v1.md
@@ -10,7 +10,7 @@ products:
# Rule types [rule-types]
-A rule is a set of [conditions](../alerts.md#rules-conditions), [schedules](../alerts.md#rules-schedule), and [actions](../alerts.md#rules-actions ) that enable notifications. {{kib}} provides rules built into the {{stack}} and rules registered by one of the {{kib}} apps. You can create most rules types in [{{stack-manage-app}} > {{rules-ui}}](create-manage-rules.md). Security rules must be defined in the Security app. For more information, refer to the documentation about [creating a detection rule](../../../solutions/security/detect-and-alert/using-the-rule-ui.md).
+A rule is a set of [conditions](../kibana-alerting-v1.md#rules-conditions), [schedules](../kibana-alerting-v1.md#rules-schedule), and [actions](../kibana-alerting-v1.md#rules-actions ) that enable notifications. {{kib}} provides rules built into the {{stack}} and rules registered by one of the {{kib}} apps. You can create most rules types in [{{stack-manage-app}} > {{rules-ui}}](create-manage-rules-v1.md). Security rules must be defined in the Security app. For more information, refer to the documentation about [creating a detection rule](../../../solutions/security/detect-and-alert/using-the-rule-ui.md).
::::{note}
Some rule types are subscription features, while others are free features. For a comparison of the Elastic subscription levels, see [the subscription page](https://www.elastic.co/subscriptions).
@@ -19,14 +19,14 @@ Some rule types are subscription features, while others are free features. For a
## Stack rules [stack-rules]
-[Stack rules](create-manage-rules.md) are built into {{kib}}. To access the **Stack Rules** feature and create and edit rules, users require the `all` privilege. See [feature privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-feature-privileges) for more information.
+[Stack rules](create-manage-rules-v1.md) are built into {{kib}}. To access the **Stack Rules** feature and create and edit rules, users require the `all` privilege. See [feature privileges](../../../deploy-manage/users-roles/cluster-or-deployment-auth/kibana-privileges.md#kibana-feature-privileges) for more information.
| | |
| --- | --- |
-| [{{es}} query](rule-type-es-query.md) | Run a user-configured {{es}} query, compare the number of matches to a configured threshold, and schedule actions to run when the threshold condition is met. |
-| [Index threshold](rule-type-index-threshold.md) | Aggregate field values from documents using {{es}} queries, compare them to threshold values, and schedule actions to run when the thresholds are met. |
+| [{{es}} query](rule-type-es-query-v1.md) | Run a user-configured {{es}} query, compare the number of matches to a configured threshold, and schedule actions to run when the threshold condition is met. |
+| [Index threshold](rule-type-index-threshold-v1.md) | Aggregate field values from documents using {{es}} queries, compare them to threshold values, and schedule actions to run when the thresholds are met. |
| [Transform rules](../../transforms/transform-alerts.md) | {applies_to}`stack: beta` {applies_to}`serverless: beta` Run scheduled checks on a {{ctransform}} to check its health. If a {{ctransform}} meets the conditions, an alert is created and the associated action is triggered. |
-| [Tracking containment](geo-alerting.md) | Run an {{es}} query to determine if any documents are currently contained in any boundaries from a specified boundary index and generate alerts when a rule’s conditions are met. |
+| [Tracking containment](geo-alerting-v1.md) | Run an {{es}} query to determine if any documents are currently contained in any boundaries from a specified boundary index and generate alerts when a rule’s conditions are met. |
## {{observability}} rules [observability-rules]
diff --git a/explore-analyze/alerting/alerts/testing-connectors.md b/explore-analyze/alerting/kibana-alerting-v1/testing-connectors-v1.md
similarity index 100%
rename from explore-analyze/alerting/alerts/testing-connectors.md
rename to explore-analyze/alerting/kibana-alerting-v1/testing-connectors-v1.md
diff --git a/explore-analyze/alerting/alerts/view-alerts.md b/explore-analyze/alerting/kibana-alerting-v1/view-alerts-v1.md
similarity index 94%
rename from explore-analyze/alerting/alerts/view-alerts.md
rename to explore-analyze/alerting/kibana-alerting-v1/view-alerts-v1.md
index 83253626ec..d0b7c93bdc 100644
--- a/explore-analyze/alerting/alerts/view-alerts.md
+++ b/explore-analyze/alerting/kibana-alerting-v1/view-alerts-v1.md
@@ -11,7 +11,7 @@ products:
# View and manage alerts in {{kib}} [view-alerts]
-When the conditions of a rule are met, it creates an alert. If the rule has actions, they run at the defined frequency. For example, the rule can send email notifications for each alert at a custom interval. For an introduction to the concepts of rules, alerts, and actions, refer to [Alerting](../alerts.md).
+When the conditions of a rule are met, it creates an alert. If the rule has actions, they run at the defined frequency. For example, the rule can send email notifications for each alert at a custom interval. For an introduction to the concepts of rules, alerts, and actions, refer to [Alerting](../kibana-alerting-v1.md).
Manage alerts from the following places:
@@ -26,7 +26,7 @@ Manage alerts from the following places:
:::
::::{note}
-You must have the appropriate {{kib}} {{alert-features}} and index privileges to view alerts. Refer to [Alerting security requirements](alerting-setup.md#alerting-security).
+You must have the appropriate {{kib}} {{alert-features}} and index privileges to view alerts. Refer to [Alerting security requirements](alerting-setup-v1.md#alerting-security).
::::
@@ -51,21 +51,21 @@ Alternatively, view those alerts in the [{{security-app}}](../../../solutions/se
To get more information about a specific alert, click the action menu icon {icon}`boxes_vertical` and select **View alert details** in either **{{stack-manage-app}} > Alerts** or **{{rules-ui}}**. There you’ll see the current status of the alert, its duration, and when it was last updated. To help you determine what caused the alert, there is information such as the expected and actual threshold values and a summarized reason for the alert.
-If an alert is affected by a maintenance window, the alert details include its identifier. For more information about their impact on alert notifications, refer to [Maintenance windows](maintenance-windows.md).
+If an alert is affected by a maintenance window, the alert details include its identifier. For more information about their impact on alert notifications, refer to [Maintenance windows](maintenance-windows-v1.md).
## Alert statuses [alert-status]
There are four common alert statuses:
`active`
-: The conditions for the rule are met. If the rule has [actions](create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings.
+: The conditions for the rule are met. If the rule has [actions](create-manage-rules-v1.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings.
`flapping`
-: The alert switched repeatedly between active and recovered states. If actions are configured to run when its status changes, they are suppressed. Refer to [Alert flapping](create-manage-rules.md#defining-rules-flapping-details) to learn more about configuring alert flapping for rules.
+: The alert switched repeatedly between active and recovered states. If actions are configured to run when its status changes, they are suppressed. Refer to [Alert flapping](create-manage-rules-v1.md#defining-rules-flapping-details) to learn more about configuring alert flapping for rules.
`recovered`
-: The conditions for the rule are no longer met. If the rule has [recovery actions](create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. Recovery actions only run if the rule's conditions aren't met during the current rule execution, but were in the previous one.
+: The conditions for the rule are no longer met. If the rule has [recovery actions](create-manage-rules-v1.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. Recovery actions only run if the rule's conditions aren't met during the current rule execution, but were in the previous one.
An active alert changes to recovered if the conditions for the rule that generated it are no longer met.
@@ -102,7 +102,7 @@ You can only mute individual alerts. To mute an alert, find the **Alerts** manag
To permanently suppress an alert's actions, open the actions menu for the appropriate alert, then select **Mark as untracked**. In this case, the alert's status is no longer updated and actions are no longer run. These changes are only applied to the alert that you untracked and cannot be reverted. Future alerts with the same alert ID are unaffected.
-To affect the behavior of the rule rather than individual alerts, check out [Snooze and disable rules](create-manage-rules.md#controlling-rules).
+To affect the behavior of the rule rather than individual alerts, check out [Snooze and disable rules](create-manage-rules-v1.md#controlling-rules).
::::
## Acknowledge alerts [acknowledge-alerts]
diff --git a/explore-analyze/alerting/kibana-alerting-v2.md b/explore-analyze/alerting/kibana-alerting-v2.md
new file mode 100644
index 0000000000..15bf79431c
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2.md
@@ -0,0 +1,134 @@
+---
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+ - id: cloud-serverless
+description: "How {{alerting-v2}} watches your data, turns conditions into signals and alerts, routes episodes through action policies and workflows, and where to go next in the docs."
+---
+
+# {{alerting-v2}} [alerting-overview-v2]
+
+{{alerting-v2}} watches your {{es}} data continuously, so your team doesn't have to. You define the conditions that matter, such as when to open an issue, who should know, and how often to notify them. The system handles the rest.
+
+## The core idea [kibana-alerting-v2-overview]
+
+{{alerting-v2}} separates *detecting* a problem from *notifying* people about it. A rule watches your data and records what it finds. Separate action policies decide who hears about it and when. This lets you build and test detection logic before wiring up any notifications, and update notification routing without touching your rules.
+
+## The four building blocks
+
+{{alerting-v2}} is built around four objects, rules, alerts, action policies, and workflows, each with a distinct role.
+
+### Rules
+A rule defines what to watch for in your data and how often to check. Every rule runs in one of two modes:
+
+- **Detect mode** - The rule records what it finds, but doesn't track whether the problem is ongoing or send any notifications. Use this for observation and investigation.
+- **Alert mode** - The rule tracks problems over time and can trigger notifications when something needs attention.
+
+Refer to [Rules](kibana-alerting-v2/rules-v2.md) to learn more.
+
+### Alerts
+When a rule runs in Alert mode, it creates an alert for each problem it detects. An alert isn't a single snapshot. It's an ongoing record that follows the problem through its full lifecycle, from when it first appeared to when it resolved. You triage and manage alerts on the **Alerts** page. Refer to [Alerts](kibana-alerting-v2/alerts-v2.md) to learn more.
+
+### Action policies
+An action policy controls whether an alert should trigger a notification, and how often. You can set conditions to filter which alerts it applies to, for example, only critical severity alerts from a specific service. A single action policy can apply to alerts from any rule in your space. Refer to [Notifications](kibana-alerting-v2/notifications-v2.md) to learn more.
+
+### Workflows
+A workflow is what actually sends the message or runs the automation, for example, posting to Slack or sending an email. Action policies hand off to workflows for delivery. Without a workflow attached, no notification is sent. Refer to [Workflows for {{alerting-v2}}](kibana-alerting-v2/workflows-alerting-v2.md) to learn more.
+
+## How the pieces fit together [how-pieces-fit-together]
+
+$$$detection-and-notification-v2$$$
+$$$runtime-execution-order$$$
+
+What happens after a rule finds something depends entirely on the rule's mode.
+
+### Alert mode
+
+Use Alert mode when you want to track issues and be notified. The rule opens an episode when the condition is met and keeps it open until the condition clears.
+
+```
+Rule runs → finds something → writes an alert event
+ → episode opens (pending → active) → you get notified
+ → condition clears (recovering → inactive) → you get notified again
+ → action policy → workflow → notification
+```
+
+1. The rule evaluates {{esql}} on a schedule and writes an alert event to `.rule-events`.
+2. The alert event joins an episode, which is tracked until the condition resolves.
+3. Action policies match eligible episodes and decide whether outreach should run.
+4. Matched policies invoke configured workflows, which deliver messages or run automation steps.
+5. Notifications are the outcome (email, chat, webhook, and so on) when all prior steps pass.
+
+#### Example: Rule runs in Alert mode
+
+An SRE team creates a rule in Alert mode that checks checkout service latency every five minutes. When p95 exceeds 2 seconds for more than one consecutive check, the rule opens an alert episode. An action policy with a `rule.labels: "checkout"` matcher picks it up, skips low-severity episodes, and sends a Slack message through an on-call workflow.
+
+The on-call engineer gets one message, investigates, fixes a slow query, and latency drops. The episode recovers automatically. No dashboard watching required.
+
+:::{image} ../images/rule-alert-mode-diagram.png
+:alt: Diagram of Alert mode flow. A rule runs ES|QL on a schedule. When it finds a match, it writes an alert event tied to an ongoing episode. The episode moves through pending, active, recovering, and inactive states. An action policy matches eligible episodes and routes them to a workflow, which delivers a notification.
+:::
+
+### Detect mode
+
+Use Detect mode when you want to record matches for querying and analysis without alerting anyone. The rule writes a signal and stops. An episode is not opened, and notifications are not sent.
+
+```
+Rule runs → finds something → writes a signal event
+ → queryable in Discover
+ → no episode, no action policy, no notification
+```
+
+#### Example: Rule runs in Detect mode
+
+A security team wants to track when a rarely-used admin API endpoint is called, not because every call is a problem, but because the pattern matters during investigations. They create a rule in Detect mode that checks for requests to that endpoint every hour.
+
+The rule writes a signal each time it finds a match. No episodes are opened and no notifications go out. When an incident is under investigation, the team queries `.rule-events` in Discover to see a full timeline of admin API activity alongside other signals, without any alert noise in between.
+
+:::{image} ../images/rule-detect-mode-diagram.png
+:alt: Diagram of Detect mode flow. A rule runs ES|QL on a schedule. When it finds a match, it writes a signal event to .rule-events. The signal is available for querying in Discover, dashboards, and ES|QL. No episode is opened, no action policy is evaluated, and no notification is sent.
+:::
+
+$$$configuration-order$$$
+
+## {{alerting-v2}} terms [key-concepts-glossary]
+
+These terms appear throughout the {{alerting-v2}} docs. If a term is unclear while reading, check its definition here before going further.
+
+**Action policy**
+: How you control who gets notified, when, and how often. You configure a matcher to filter which alerts it applies to, how episodes batch into notifications (Dispatch per), and which workflow should send the message. One action policy can apply to alerts from multiple rules. To learn more, refer to [Notifications](kibana-alerting-v2/notifications-v2.md).
+
+**Alert**
+: A rule event produced when a rule runs in Alert mode. Unlike a signal, an alert is tied to an ongoing episode and is part of the full story of that problem from when it started to when it resolved.
+
+**Breach**
+: A single moment when a rule's query finds a match. One breach doesn't necessarily trigger a notification. You can configure a rule to require several consecutive breaches before it confirms the problem is real.
+
+**Episode**
+: The complete record of one problem, from when it was first detected to when it recovered. An episode moves through states (pending, active, recovering, inactive) as the situation changes. This is what you see and act on in the Alerts UI. To learn more, refer to [Alerts](kibana-alerting-v2/alerts-v2.md).
+
+**{{esql}}**
+: The query language every rule uses to search your data. To learn more, refer to the [{{esql}} reference](elasticsearch://reference/query-languages/esql.md).
+
+**Notification**
+: The message or action delivered when an alert matches an action policy and a workflow sends it. Examples include a Slack message, an email, or a webhook call. To learn more, refer to [How action policies are evaluated](kibana-alerting-v2/notifications-v2.md#how-action-policies-evaluated-v2).
+
+**Rule**
+: The definition of what to watch for in your data, how often to check, and what counts as a problem. Rules run on a schedule. In Detect mode they produce signals. In Alert mode they track ongoing episodes. To learn more, refer to [Rules](kibana-alerting-v2/rules-v2.md).
+
+**Rule event**
+: A record written to `.rule-events` every time a rule runs and its query finds a match. Every rule produces rule events. Whether the record is a signal or an alert depends on the mode the rule is running in.
+
+**Severity**
+: A label you can attach to alerts to indicate how serious they are. Severity is available as a filter in action policies, so you can route critical alerts differently from low-priority ones. To learn more, refer to [Author rules](kibana-alerting-v2/rules/author-rules-v2.md#severity-levels).
+
+**Signal**
+: A rule event produced when a rule runs in Detect mode. Signals are stored and queryable, but they don't open episodes or trigger notifications.
+
+**Threshold**
+: The condition a rule uses to decide when something is worth alerting on. This includes both the query that detects the problem and settings that control how many times the condition must be met before an alert opens or closes. To learn more, refer to [Conditions and thresholds](kibana-alerting-v2/rules/author-rules-v2.md#conditions-and-thresholds).
+
+**Workflow**
+: The automation that sends a message or runs an action when an action policy decides a notification should go out. Examples include posting to Slack, sending an email, or calling a webhook. To learn more, refer to [Workflows for {{alerting-v2}}](kibana-alerting-v2/workflows-alerting-v2.md).
diff --git a/explore-analyze/alerting/kibana-alerting-v2/alerting-v2-privileges.md b/explore-analyze/alerting/kibana-alerting-v2/alerting-v2-privileges.md
new file mode 100644
index 0000000000..ababb44325
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/alerting-v2-privileges.md
@@ -0,0 +1,32 @@
+---
+navigation_title: Privileges
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+ - id: cloud-serverless
+description: "Privilege requirements for {{alerting-v2}}: what {{kib}} feature access and {{es}} index access each role needs to manage rules, policies, alerts, and query alert data."
+---
+
+# {{alerting-v2}} privileges [alerting-privileges-v2]
+
+$$$alerting-privileges-v2$$$
+
+
+
+## Manage rules [alerting-manage-rules-privileges]
+
+[CONTENT NEEDED]
+
+## Manage action policies [action-policy-management]
+
+[CONTENT NEEDED]
+
+## Manage alerts [alerting-manage-alerts-privileges]
+
+[CONTENT NEEDED]
+
+## Query alert data in Discover [alerting-discover-privileges]
+
+[CONTENT NEEDED]
diff --git a/explore-analyze/alerting/kibana-alerting-v2/alerts-v2.md b/explore-analyze/alerting/kibana-alerting-v2/alerts-v2.md
new file mode 100644
index 0000000000..e19b3e11ce
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/alerts-v2.md
@@ -0,0 +1,141 @@
+---
+navigation_title: Alerts
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Alert episodes in {{alerting-v2}}: lifecycle states, series and episodes, signals versus alerts, and where to find them."
+---
+
+# {{alerting-v2}} alerts
+
+When a rule fires repeatedly on the same problem, a flat list of events doesn't tell you when the issue started, whether it's still happening, or how long it's been going on. Alert episodes fill that gap. Each episode is a persistent record of one issue on one series, from first breach through recovery, with every evaluation appended to the same history. Nothing is overwritten.
+
+
+
+## Alert lifecycle [alert-lifecycle-v2]
+
+Every alert episode moves through these states:
+
+```
+inactive → pending → active → recovering → inactive
+```
+
+| State | What it means |
+| --- | --- |
+| Inactive | Problem fully resolved. You get a recovery notification. |
+| Pending | Errors detected, but the system is waiting to confirm it's a real problem before fully alerting. |
+| Active | Problem confirmed and ongoing. This is when you get notified. |
+| Recovering | Errors have stopped, but the system is waiting to confirm it's truly resolved. |
+
+Activation and recovery thresholds control how many consecutive evaluations must agree, or how long the condition must persist, before transitioning. Refer to [Configure a rule](rules/configure-a-rule-v2.md#activation-recovery-thresholds-v2) to learn more about these settings.
+
+### Example: First breach opens, first clear closes
+
+A checkout-latency rule runs in Alert mode every 5 minutes. Latency breaches at 14:05 and clears at 14:50:
+
+1. **14:00** — Routine check. p95 is within budget. The episode is `inactive`.
+2. **14:05** — p95 jumps to 3.1s. The first breach is detected. With no activation threshold, the episode opens immediately as `active`.
+3. **14:10–14:45** — Every evaluation finds high latency. The same episode stays `active`. No new episodes are created.
+4. **14:50** — p95 drops back under 2s. With no recovery threshold, the episode resolves immediately to `inactive`.
+
+One problem is tracked in one episode, even though the rule evaluated many times while the condition was ongoing.
+
+:::{image} ../../images/alert-episode-example-without-threshold.png
+:alt: Timeline of a checkout-latency alert episode without thresholds. At 14:05, p95 jumps to 3.1s and the episode opens immediately as active. It stays active through 14:45. At 14:50, p95 drops back under 2s and the episode resolves immediately as inactive.
+:::
+
+### Example: Waiting for confirmation before opening and closing
+
+The same checkout-latency rule, now with an activation threshold of 2 consecutive breaches and a recovery threshold of 2 consecutive clears:
+
+1. **14:00** — Routine check. p95 is within budget. The episode is `inactive`.
+2. **14:05** — p95 jumps to 3.1s. The first breach is detected. The episode is created in `pending` and the system starts counting consecutive breaches.
+3. **14:10** — p95 is still elevated. The second consecutive breach meets the activation threshold. The episode moves from `pending` to `active`, and the engineer is paged.
+4. **14:10–14:45** — Latency stays elevated. The episode remains `active`.
+5. **14:50** — p95 drops back under 2s. The first clean check moves the episode to `recovering`. The system starts counting consecutive clears.
+6. **14:55** — A second consecutive clear meets the recovery threshold. The episode moves from `recovering` to `inactive`.
+
+Thresholds prevent brief spikes from opening episodes and transient dips from closing them prematurely. The episode waits in `pending` until the problem is confirmed, and waits in `recovering` until the resolution is confirmed.
+
+:::{image} ../../images/alert-episode-example-with-activation-threshold.png
+:alt: Timeline of a checkout-latency alert episode with activation threshold of 2 and recovery threshold of 2. At 14:05, the first breach puts the episode in pending. At 14:10, the second consecutive breach moves it to active. At 14:50, the first clean check moves it to recovering. At 14:55, the second consecutive clear resolves it to inactive.
+:::
+
+## Series
+
+A series is the ongoing relationship between a rule and one specific thing it monitors.
+
+Your rule monitors services. Each service it tracks has its own series, one for `checkout-service`, one for `payment-service`, and so on. A series exists for as long as that rule keeps monitoring that service.
+
+Think of it like a patient's medical file. The file exists as long as the patient is in the system. Individual health incidents come and go, but the file persists.
+
+For the fields that identify a series in alert event documents, refer to [Rule event and field reference](rules/rule-event-field-reference-v2.md#rule-reference-v2).
+
+### How series and episodes relate
+
+An episode lives inside a series. A series can contain many episodes over its lifetime, one for each time that service had a problem.
+
+```
+Series: checkout-service
+│
+├── Episode 1: errors on April 10 (active → inactive)
+├── Episode 2: errors on April 15 (active → inactive)
+└── Episode 3: errors on April 18 (active right now)
+```
+
+The series is the container. Episodes are the individual problems that happened within it. When the series breaches again after recovering, a new episode starts.
+
+This means you can track "the checkout service was broken from 02:14 to 03:21" and "the payment service was broken at the same time" as separate episodes, even when both come from the same rule.
+
+:::{tip}
+Snooze operates at the series level, not the episode level. If you snooze `checkout-service`, you're silencing all notifications from that series for the next X hours, regardless of how many new episodes start during that time. You're quieting a specific ongoing situation, not a single alert.
+:::
+
+### A practical way to think about it
+
+| Concept | Analogy |
+| --- | --- |
+| Rule | A security camera watching the building |
+| Series | The camera's feed for one specific door |
+| Episode | A specific incident caught on that feed |
+| Rule events | The individual video frames |
+
+The camera runs continuously (rule), always watching door 3 (series). One night someone breaks in. That's an episode. The frames captured during the break-in are the rule events.
+
+## Signals versus alerts
+
+Every time a rule finds a match, it writes a document to `.rule-events`. Whether that document is a signal or an alert depends on the rule's mode, and that choice determines whether the system only records what happened or actively tracks it through to resolution.
+
+A **signal** is a one-time observation. The system writes it and moves on, no lifecycle, no notifications, no follow-up. An **alert** participates in an episode. The system links it to every other document from the same problem, tracks the lifecycle states, and routes notifications through action policies.
+
+| Type | What it is | When it's created |
+| --- | --- | --- |
+| Signal | A point-in-time record that the query matched (`type: signal`). Stored in `.rule-events`. | Rules in Detect mode |
+| Alert | A lifecycle-tracked episode with `type: alert` and `episode.*` fields. Stored in `.rule-events`. | Rules in Alert mode |
+
+A rule in Detect mode only writes signals. It never opens episodes, so action policies have nothing to match against.
+
+## Where alerts live
+
+Alert events are stored in `.rule-events`. Triage actions (acknowledge, snooze, resolve) are stored in `.alert-actions`. Both are queryable in Discover.
+
+
+
+### Data stream storage and retention
+
+Both `.rule-events` and `.alert-actions` are data streams, append-only, time-series stores optimized for writes. On every rule evaluation, {{kib}} writes a **new document** to `.rule-events` rather than updating the previous one. Each document is a point-in-time snapshot. The `episode.status` field records the lifecycle state the episode was in at that exact evaluation. Nothing is overwritten.
+
+Because every evaluation produces its own document, you can reconstruct the full history of an episode by querying all documents that share the same `episode.id`. Refer to [Query alerts and signals in Discover](alerts/query-alerts-and-signals-in-discover-v2.md#explore-alerts-discover-v2) for example queries.
+
+Retention is managed automatically through ILM. Older backing indices move through storage tiers and are deleted when the retention window expires. You do not need to manually remove documents. {{kib}} manages versioning, retention, and lifecycle for both streams. Do not change their mappings or index settings.
+
+## Related pages
+
+- **[View, manage, and reference alerts](alerts/view-and-manage-alerts-v2.md):** Open the alert episodes table, triage active episodes, and acknowledge, snooze, or resolve them.
+- **[Query alerts and signals in Discover](alerts/query-alerts-and-signals-in-discover-v2.md):** Use {{esql}} to query `.rule-events` and `.alert-actions` for ad hoc analysis and dashboards.
+- **[Alert states and fields reference](alerts/alert-states-and-fields-reference-v2.md):** Look up lifecycle states, field names, and episode document structure.
+- **[Notifications](notifications-v2.md):** Set up action policies to route alert episodes to the right people and channels.
diff --git a/explore-analyze/alerting/kibana-alerting-v2/alerts/alert-states-and-fields-reference-v2.md b/explore-analyze/alerting/kibana-alerting-v2/alerts/alert-states-and-fields-reference-v2.md
new file mode 100644
index 0000000000..93072e37c1
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/alerts/alert-states-and-fields-reference-v2.md
@@ -0,0 +1,56 @@
+---
+navigation_title: Alert states and fields
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Reference for {{alerting-v2}} episode status, `.rule-events` row status, and `.alert-actions` document fields."
+---
+
+# Alert states and fields reference [alert-states-reference-v2]
+
+$$$alert-states-reference-v2$$$
+
+Use these tables when you read alert UI state, query `.rule-events` or `.alert-actions` in Discover, or align API payloads with what operators see. For triage controls (acknowledge, snooze, resolve, tags) and how they map to storage, refer to [Alert actions](view-and-manage-alerts-v2.md#alert-actions-v2). For rule evaluation fields on `.rule-events`, refer to [Rule event and field reference](../rules/rule-event-field-reference-v2.md#rule-reference-v2).
+
+## Episode status
+
+The `episode.status` field appears on documents with `type: alert` in `.rule-events`. It represents the current lifecycle state of the alert episode.
+
+| Value | Description |
+|---|---|
+| `inactive` | Episode not in an active breach state in the lifecycle model. |
+| `pending` | Condition met but activation thresholds not yet satisfied. |
+| `active` | Episode is actively breaching per rule logic. |
+| `recovering` | Condition clearing but recovery thresholds not yet satisfied. |
+
+
+
+## Rule event status
+
+The `status` field appears on all documents in `.rule-events`, for both `type: signal` and `type: alert`. It reflects the outcome of a single rule evaluation row, independent of the episode lifecycle.
+
+| Value | Description |
+|---|---|
+| `breached` | Condition met for this evaluation row. |
+| `recovered` | Recovery path satisfied for this evaluation row. |
+| `no_data` | No-data handling produced a no-data style outcome for this evaluation. |
+
+## Alert action document fields
+
+When a user or the system records an action on an alert episode, {{kib}} writes a document to `.alert-actions`. Use this stream for triage history, operational metrics such as mean time to acknowledge (MTTA), and auditing. It does not store what your rule query returned on each run — that output is in `.rule-events`.
+
+| Field | Type | Description |
+|---|---|---|
+| `@timestamp` | date | When the action was recorded. |
+| `episode.id` | keyword | Target episode. |
+| `rule.id` | keyword | Rule that owns the episode. |
+| `action.type` | keyword | The action type, for example:
- `acknowledge`: User acknowledged the alert.
- `snooze`: Notifications snoozed for a period.
- `tag`: Tag applied to the alert.
- `fire`: Notification or escalation fired for the episode.
- `unmatched`: No action policy matched the episode, so no workflow ran for it under these policies.
For the full set of action types and UI behavior, refer to [Alert actions](view-and-manage-alerts-v2.md#alert-actions-v2). |
+| `episode.status_count` | long | Count of consecutive evaluations in the current `episode.status`. Only set when `episode.status` is `pending` or `recovering`.
For example, if the episode stays `pending` for three rule evaluations in a row, the value is `3`. |
diff --git a/explore-analyze/alerting/kibana-alerting-v2/alerts/query-alerts-and-signals-in-discover-v2.md b/explore-analyze/alerting/kibana-alerting-v2/alerts/query-alerts-and-signals-in-discover-v2.md
new file mode 100644
index 0000000000..0b6bf54676
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/alerts/query-alerts-and-signals-in-discover-v2.md
@@ -0,0 +1,27 @@
+---
+navigation_title: Query alerts in Discover
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Use {{esql}} in Discover against `.rule-events` and `.alert-actions`: sample queries, trends, and MTTA-style analysis for {{alerting-v2}}."
+---
+
+# Query alerts and signals in Discover [explore-alerts-discover-v2]
+
+$$$explore-alerts-discover-v2$$$
+
+Discover gives you direct {{esql}} access to everything {{alerting-v2}} records, including rule evaluation history, episode progressions, triage actions, and operational metrics like mean time to acknowledge.
+
+The Alerts UI shows current episode state. Discover lets you go further: ask arbitrary questions, spot trends over time, replay how a specific incident unfolded, or correlate alert history with other data in your environment.
+
+To use this page, open Discover, select {{esql}}, paste a query from the examples below, then adjust the time range and placeholders (`YOUR_RULE_ID`, `YOUR_GROUP_HASH`) to match your environment.
+
+
+
+For field names, types, and episode fields, refer to [Alert states and fields reference](alert-states-and-fields-reference-v2.md#alert-states-reference-v2) and [Rule event and field reference](../rules/rule-event-field-reference-v2.md#rule-reference-v2). For triage in the product UI, refer to [View, manage, and reference alerts](view-and-manage-alerts-v2.md).
+
diff --git a/explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md b/explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md
new file mode 100644
index 0000000000..d793a4fcbf
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md
@@ -0,0 +1,124 @@
+---
+navigation_title: View and manage alerts
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Open the {{alerting-v2}} alert episodes table, triage actions, and episode details. Field and state tables live on a separate reference page."
+---
+
+# View and manage alerts [manage-alerts-v2]
+
+$$$manage-alerts-v2$$$
+
+When a rule detects a problem, use the Alerts UI to understand what's happening and decide what to do about it. From here you can examine alert episodes, use filters to find what needs attention, triage alerts, and more. This is the operational surface for working through alerts day to day.
+
+
+
+## Filter and search
+
+- **Rule:** Limit rows to one or more rules.
+- **Status:** Limit by episode lifecycle state (active, recovered, pending, inactive).
+- **Tags:** Limit to episodes whose last tag set matches any selected tag (OR logic). Tag choices come from tag actions in the selected time range.
+- **Search:** Text search runs over alert event document fields. Combine with **Rule** or **Tags** filters when looking for a specific rule or label.
+
+Narrow the time range when filters return too many rows or when tag options need refreshing.
+
+## Episode actions
+
+From any row in the table you can:
+
+- **Acknowledge / Unacknowledge:** Applies to the individual episode.
+- **Snooze / Unsnooze:** Applies to the series (`group_hash`), so all rows in that series are affected.
+- **Resolve / Unresolve:** Applies to the series. The episode shows as inactive in the UI when resolved, even if the underlying lifecycle data has not yet caught up.
+- **Edit tags:** Opens a flyout where you can add new tags to the episode or remove existing ones. Tag changes apply to the individual episode and are persisted as `tag` actions in `.alert-actions`. Tags added this way appear in the **Tags** filter on the alerts table and can be queried in Discover for reporting and triage workflows.
+
+The same actions are available from the episode detail page.
+
+### Snooze an episode [snooze-episode-v2]
+
+$$$snooze-episode-v2$$$
+
+Snoozing suppresses notifications for an alert series for a defined period. When you select **Snooze** on a row, a popover opens where you set a duration. During the snooze window, the rule continues to evaluate, and the episode stays visible in the alerts table, but notifications are not sent.
+
+Snooze applies at the series level. All episodes sharing the same `group_hash` are silenced for the duration, not just the row you acted on. Use snooze when a known condition is expected to persist for a fixed time and you want to stop the noise without disabling the rule entirely. The snooze expires automatically when the duration ends.
+
+## Open in Discover
+
+Select **Discover** on a row to investigate source data. Discover opens with the rule {{esql}} query and a short time window around the episode so you can inspect matching documents in context.
+
+For ad hoc analysis over `.rule-events` and `.alert-actions` with copy-paste {{esql}} examples, refer to [Query alerts and signals in Discover](query-alerts-and-signals-in-discover-v2.md).
+
+## Episode detail page [alert-episode-details-v2]
+
+$$$alert-episode-details-v2$$$
+$$$investigate-respond-v2$$$
+
+Open an episode's detail page by selecting its name or ID from the table row. The detail page shows:
+
+- **Lifecycle:** A state-over-time visualization (pending, active, recovering, inactive) driven by events in `.rule-events`.
+- **Actions and metadata:** Tags and action-driven status (acknowledge, snooze, resolve) consistent with the episodes table.
+- **Related episodes:** Other episodes on the same rule or series, split into two subsections for easier triage.
+- **Actors:** Users who have taken actions on the episode, visible so teams can track activity and accountability.
+- **Metadata:** A dedicated tab surfacing additional fields from the source event that triggered the alert.
+- **Grouping:** When the rule uses grouping, the detail view surfaces the field values that identify the series.
+
+### Related episodes [related-episodes-v2]
+
+$$$related-episodes-v2$$$
+
+The **Related episodes** section is split into two subsections that help you distinguish between a condition that keeps recurring on one entity and a rule that is triggering across many different entities:
+
+- **Same alert series:** Other episodes sharing the same `rule_id` and `group_hash` as the current episode. These represent recurrences of the exact same alert condition — the same rule firing on the same series (for example, the same host or service). If this list is long, the condition is repeating and the underlying issue may not be fully resolved each time.
+- **Other series for this rule:** Episodes from the same rule but with a different `group_hash`, or all other rule episodes when the rule does not use grouping. These show broader rule activity — other entities or conditions the same rule is also triggering on. Use this list to understand the rule's overall blast radius and whether a problem is isolated to one entity or affecting many.
+
+### Metadata tab [metadata-tab-v2]
+
+$$$metadata-tab-v2$$$
+
+The **Metadata** tab surfaces additional information about the alert episode that is not shown in the main detail view. This includes field values from the source event that triggered the alert, giving you direct access to the raw signal during triage without switching to Discover.
+
+Use the **Metadata** tab when you need to inspect specific field values that are embedded in the alert's source data but not surfaced in the lifecycle or grouping sections. For example, use the tab to identify a rule's resources or version.
+
+### Actors [actors-v2]
+
+$$$actors-v2$$$
+
+The **Actors** section lists the users who have taken actions on the episode (who acknowledged it, who snoozed it, and who resolved it) and when each action was taken. This gives teams visibility into the response history for an episode, which is useful for accountability and coordination.
+
+## Alert actions [alert-actions-v2]
+
+$$$alert-actions-v2$$$
+
+When you take an action, {{kib}} writes a document to the `.alert-actions` data stream. You can query these documents in Discover for auditing and metrics such as mean time to acknowledge (MTTA). For a full field list and state definitions, refer to [Alert states and fields reference](alert-states-and-fields-reference-v2.md#alert-states-reference-v2).
+
+### Episode scope versus series scope
+
+Some actions apply only to the specific episode you acted on. Others apply to every episode in the same series, meaning all episodes that share the same rule and `group_hash`. This matters when a rule tracks multiple services or hosts. Snoozing one episode silences the whole series, not only that service.
+
+| Action | Scope |
+|---|---|
+| Acknowledge / Unacknowledge | Episode |
+| Snooze / Unsnooze | Series |
+| Resolve / Unresolve | Series |
+| Edit tags | Episode |
+
+## How suppression works [suppression-mechanics-v2]
+
+$$$suppression-mechanics-v2$$$
+
+Suppression controls whether a matched alert episode actually sends a notification. The dispatcher evaluates suppression before any action policy matcher runs, so a suppressed episode never reaches routing, grouping, or frequency checks.
+
+
+There are three suppression options, each with a different scope:
+
+| Option | Scope | When to use |
+|---|---|---|
+| Acknowledge | Per episode | You're actively working on a specific breach and want to silence notifications for it. To clear suppression, remove the acknowledgement. |
+| Deactivate | Per episode | Marks the episode as inactive and stops notifications for it. Unlike acknowledge, this closes the episode rather than silencing it while leaving it active. Use when you want to manually close a specific episode, for example, when you've addressed the issue but the rule hasn't recovered automatically. |
+| Snooze | Per series | You want to quiet an entire alert series for a defined period. For example, during a known noisy window for a host. Expires automatically. |
+
+
diff --git a/explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md b/explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md
new file mode 100644
index 0000000000..d0bcca3737
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md
@@ -0,0 +1,80 @@
+---
+navigation_title: Notifications
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "How {{alerting-v2}} action policies route alert episodes to notifications: matchers, grouping, frequency, and workflow destinations."
+---
+
+# {{alerting-v2}} notifications
+
+After a rule produces alert episodes, action policies decide what to do about them: who gets notified, how often, and through which channel.
+
+This page explains how action policies work. For creating and configuring them step by step, refer to [Create and configure an action policy](notifications/create-configure-action-policy-v2.md).
+
+## What is an action policy [action-policies-v2]
+
+$$$action-policies-v2$$$
+
+An action policy is a saved object in your space that controls notification routing. It's not attached to a rule. It's global within the space, so when an episode is produced, the system evaluates all enabled policies in the space that are not snoozed and decides which ones apply.
+
+Each policy has four controls:
+
+| Control | What it does |
+| --- | --- |
+| Matcher (optional KQL) | Filters which episodes this policy applies to. An empty matcher matches all episodes in the space. |
+| Dispatch per (grouping) | Controls how episodes batch into notifications: one per episode, one per notification group (Dispatch per **Group**), or one digest for all. |
+| Frequency | Controls how often the policy can notify for the same notification group. |
+| Destinations | One or more workflows to invoke when all conditions are met. |
+
+## How policies apply to rules
+
+Action policies don't reference rules directly. You scope a policy using KQL over episode and rule fields, for example `rule.labels: "checkout"` or `data.severity: "critical"`. A policy applies to every matching episode in the space, from any rule.
+
+Multiple policies can match the same episode, and each runs independently. There's no precedence or merging between them. If no policy matches an episode, no notification is sent. This is intentional.
+
+## How action policies are evaluated [how-action-policies-evaluated-v2]
+
+$$$how-action-policies-evaluated-v2$$$
+
+When an episode is eligible for dispatch, the system processes each enabled policy that is not snoozed, in order:
+
+1. **Suppression:** Is the episode acknowledged, snoozed, or deactivated? If so, skip dispatch.
+2. **Matcher:** Does the episode match the policy's KQL? If not, skip this policy.
+3. **Grouping:** How should matching episodes batch into notification groups?
+4. **Frequency:** Has a notification already gone out for this notification group recently? If so, wait.
+5. **Destinations:** Send to the policy's workflow destinations.
+
+The dispatcher runs on a short interval (around 5 seconds). Notifications don't arrive on the exact rule schedule. They follow the dispatcher's own cycle.
+
+### Possible outcomes [possible-outcomes]
+
+Each notification attempt results in one of the following outcomes.
+
+| Outcome | What it means |
+| --- | --- |
+| `dispatched` | A notification was sent. |
+| `throttled` | Dispatch was suppressed because the **frequency** interval had not elapsed. |
+| `suppressed` | The episode was suppressed before dispatch (acknowledged, snoozed, or deactivated). |
+| `unmatched` | No policy matched this episode; no workflow ran. |
+| `error` | Processing failed. Check {{kib}} logs. |
+
+You can query these outcomes in Discover through the `.alert-actions` data stream.
+
+## Why policies are separate from rules
+
+Rules don't own policies. A rule can't say "notify team X when it fires." Instead, team X creates an action policy that uses a KQL matcher to pick up matching episodes.
+
+This design means:
+- One policy can cover episodes from many rules.
+- You can update routing without touching any rule.
+- Rules can be created without any notification policy, which is useful for testing.
+
+When you're ready to route notifications, go to [Create and configure an action policy](notifications/create-configure-action-policy-v2.md).
+
+$$$matcher-v2$$$
+$$$reduce-noise-grouping-v2$$$
+$$$throttle-v2$$$
+$$$create-manage-action-policies-v2$$$
diff --git a/explore-analyze/alerting/kibana-alerting-v2/notifications/action-policy-reference-v2.md b/explore-analyze/alerting/kibana-alerting-v2/notifications/action-policy-reference-v2.md
new file mode 100644
index 0000000000..788244b688
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/notifications/action-policy-reference-v2.md
@@ -0,0 +1,100 @@
+---
+navigation_title: Action policy reference
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Grouping modes, frequency options, dispatch outcomes, and matcher field reference for {{alerting-v2}} action policies."
+---
+
+# Action policy reference [action-policy-reference-v2]
+
+$$$action-policy-reference-v2$$$
+
+Use this page when building action policies. Below, you will find details about valid matcher fields, grouping modes and frequency options, dispatch outcome, and more. For step-by-step guidance, refer to [Create and configure an action policy](create-configure-action-policy-v2.md).
+
+## Matcher fields [matcher-fields]
+
+Use these fields in the **Matcher** expression to filter which episodes a policy applies to. Combine them with standard KQL operators, for example `data.severity: "critical" AND episode_status: "active"`.
+
+| Field | Description | Example |
+|---|---|---|
+| `episode_status` | Current lifecycle status of the episode. Accepted values: `active`, `inactive`, `pending`, `recovering`. | `episode_status: "active"` |
+| `data.*` | Dynamic payload fields sent by the rule. Available fields depend on the rule type and configuration. | `data.severity: "critical"` or `data.host.name: "web-01"` |
+| `rule.id` | Unique identifier for the rule that generated the episode. | `rule.id: "rule-001"` |
+| `rule.name` | Display name of the rule. | `rule.name: "High CPU"` |
+| `rule.labels` | Key-value labels attached to the rule. Use dot notation to target a specific label key. | `rule.labels.env: "production"` |
+
+
+
+## Dispatch per options [notification-grouping]
+
+Controls how the policy batches matching episodes before sending a notification.
+
+| Option | Description | When to use |
+|---|---|---|
+| Episode | Each episode triggers its own notification independently. Default selection. | You need per-issue visibility and want to handle each problem separately. |
+| Group | The policy bundles episodes that share the same value for a specified `data.*` field into one notification per unique value (a **notification group**). | A rule produces many related episodes (for example, one per service or host) and you want to reduce noise by batching them into shared notifications. |
+| Digest | The policy combines all matching episodes into a single notification, regardless of what they have in common. | You want a single periodic summary of everything that matched, rather than individual alerts. |
+
+## Frequency [throttle-strategies]
+
+**Frequency** controls how often the policy fires for a given episode or notification group. The available options depend on the **Dispatch per** setting. Not all options are valid for all modes.
+
+| Option | Description | When to use |
+|---|---|---|
+| On status change | Notifies when the episode status changes (for example, active → recovering). One notification per transition. | You only need to know when something breaks and when it's resolved. No reminders needed. |
+| On status change + repeat at interval | Notifies on status change, then resends notifications at a regular interval while the episode remains in the same status. | You want status change alerts plus periodic notifications that a problem is still unresolved, in case it has been missed or pushed aside. |
+| At most once every… | Caps notifications at one per episode or notification group within the chosen interval, regardless of rule frequency. | You want to limit alert volume for noisy rules without missing new or ongoing issues. |
+| Every evaluation | Notifies on every rule evaluation. Can be noisy. Use sparingly and only with infrequent rule schedules. | You need a full audit trail of every evaluation, or the rule runs infrequently enough that noise isn't a concern. |
+
+
+
+### Frequency options for Episode [frequency-when-episode-per_episode]
+
+Available frequency options when you set **Dispatch per** to **Episode**.
+
+| Option | Description | Example |
+|---|---|---|
+| On status change | Notifies once when the episode opens and once when it recovers. No repeat notifications while it remains active. Best for when you trust your ticketing or incident workflow to track ongoing issues | A host goes down at 9:00am → one notification. Recovers at 11:00am → one notification. No notifications between them. |
+| On status change + repeat at interval | Same as On status change, but also sends a reminder at a set interval while the episode is still active. | A host goes down at 9:00am → notification. With a 1h repeat: reminder at 10:00am, 11:00am. Recovers at 11:30am → notification. |
+| Every evaluation | Fires on every rule evaluation, regardless of status. Can be noisy on frequent rule schedules. Avoid in production. | A rule running every 5 minutes with one active episode produces up to 288 notifications per day. |
+
+### Frequency options for Group
+
+Available frequency options when you set **Dispatch per** to **Group**.
+
+| Option | Description | Example |
+|---|---|---|
+| At most once every… | Limits how often each notification group can notify, regardless of how many episodes match or how often the rule runs. | 10 episodes share `data.host.name: "web-01"`. With a 1h limit, you get at most one notification per hour for that notification group. |
+| Every evaluation | Fires on every rule evaluation for each unique value in the group-by field. Still noisy on frequent rule schedules. | A rule running every 10 minutes with 5 unique host values produces up to 6 notifications per host per hour. |
+
+### Frequency options for Digest
+
+Available frequency options when you set **Dispatch per** to **Digest**.
+
+| Option | Description | Example |
+|---|---|---|
+| Every evaluation | The only option for Digest. Fires on every rule run, bundling all matching episodes into one message. Pair with a longer rule schedule to avoid frequent summary messages. | A rule running every 30 minutes with 20 matching episodes produces one summary notification every 30 minutes containing all 20. |
+
+## Dispatch outcomes
+
+The system records each notification attempt with one of the following outcomes. To investigate delivery issues, query the `.alert-actions` data stream in Discover and filter by the `outcome` field.
+
+| Outcome | What happened |
+|---|---|
+| `dispatched` | The system sent the notification successfully. |
+| `throttled` | The system skipped delivery because the **frequency** interval had not elapsed. This is expected behavior, not an error. |
+| `suppressed` | Dispatch was blocked before the notification went out—the rule was acknowledged, snoozed, or deactivated. |
+| `unmatched` | No action policy matched this episode, so no workflow ran. |
+| `error` | An error occurred during processing. Check {{kib}} logs to identify the cause. |
\ No newline at end of file
diff --git a/explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md b/explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md
new file mode 100644
index 0000000000..4b8d027b00
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md
@@ -0,0 +1,71 @@
+---
+navigation_title: Create an action policy
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Create {{alerting-v2}} action policies, configure matchers, Dispatch per, Frequency, and workflow destinations."
+---
+
+# Create and configure an action policy [create-manage-action-policies-v2]
+
+$$$create-manage-action-policies-v2$$$
+
+Rules define what counts as a problem. Action policies define what happens when a problem is detected. They determine which episodes generate notifications, how episodes batch for dispatch, **frequency** limits on notifications, and where they're routed.
+
+Because policies are separate from rules and global within a space, you can update notification behavior across many rules at once without touching detection logic, and you can route the same alerts differently depending on severity or source. You create and manage policies from the **Action policies** page, not from the rule form.
+
+For matcher fields, grouping modes, frequency options, and dispatch outcomes, refer to [Action policy reference](action-policy-reference-v2.md).
+
+
+
+## Policy fields [policy-fields]
+
+### Matcher [matcher-v2]
+
+$$$matcher-v2$$$
+
+An optional KQL expression that filters which episodes this policy applies to. An empty matcher matches every episode in the space.
+
+Use matchers to route different episodes to different policies, for example, one policy for `data.severity: "critical"` episodes routed to PagerDuty and another for warnings routed to Slack. For available fields and examples, refer to [Matcher fields](action-policy-reference-v2.md#matcher-fields).
+
+
+
+### Grouping and frequency [reduce-noise-grouping-v2]
+
+$$$reduce-noise-grouping-v2$$$
+
+**Dispatch per** controls how episodes batch into notifications. **Frequency** controls how often the policy can notify for each batch.
+
+:::{table}
+:widths: 4-4-4
+
+| Dispatch per | What it does | Available Frequency options |
+|---|---|---|
+| Episode | One notification per episode. | - On status change
- On status change + repeat at interval
- Every evaluation |
+| Group | Bundle episodes that share a field value. Specify **Group by** (for example `data.service.name` or `data.host.name`). | - At most once every…
- Every evaluation |
+| Digest | One notification for all matching episodes combined. | Every evaluation |
+
+:::
+
+For detailed descriptions, frequency options, and examples for each mode, refer to [Dispatch per options](action-policy-reference-v2.md#notification-grouping).
+
+### Frequency [throttle-v2]
+
+$$$throttle-v2$$$
+
+**Frequency** limits how often the policy can fire for a given notification group. The interval resets from the last time the policy fired, so successive notifications stay at least `interval` apart. Set a duration such as `1h` or `30m`. For available options by **Dispatch per** mode, refer to [Frequency](action-policy-reference-v2.md#throttle-strategies).
+
+### Destinations
+
+One or more workflows to invoke when the policy matches. Use the search field to find and attach workflows.
+
+### Snooze
+
+An optional time window during which the policy doesn't dispatch. Useful for planned maintenance or quiet periods without disabling the policy entirely.
diff --git a/explore-analyze/alerting/kibana-alerting-v2/notifications/manage-action-policies-v2.md b/explore-analyze/alerting/kibana-alerting-v2/notifications/manage-action-policies-v2.md
new file mode 100644
index 0000000000..1ad00e250e
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/notifications/manage-action-policies-v2.md
@@ -0,0 +1,35 @@
+---
+navigation_title: Manage action policies
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Enable, disable, snooze, maintenance windows, bulk actions, and API key rotation for {{alerting-v2}} action policies."
+---
+
+# Manage action policies
+
+After you create an action policy, you can control when it runs, pause it temporarily, and keep its credentials current. This page covers those management tasks.
+
+## Enable, snooze, and maintenance
+
+You can disable a policy so it is not evaluated for new episodes. You can snooze a policy for a defined window so that it does not dispatch notifications during that period. Policies that are not enabled or are snoozed are skipped when the dispatcher evaluates policies.
+
+### Maintenance windows [maintenance-windows-v2]
+
+$$$maintenance-windows-v2$$$
+
+Maintenance windows are scheduled periods during which a policy does not dispatch notifications. They are configured on the action policy alongside snooze and other policy controls, not on the rule. Rule evaluation continues and alert episodes can still be recorded in `.rule-events`. Only dispatch through that policy pauses. Use maintenance windows for planned deployments, infrastructure changes, or recurring quiet periods.
+
+## Update API keys
+
+You can rotate the API key used to run a policy's workflows without changing matchers or destinations. Use the **Update API key** action on one policy or for multiple selected policies.
+
+::::{important} Production considerations
+When you update or delete an action policy, previous API keys used for execution are marked for invalidation and removed on a schedule managed by {{kib}}. Allow for a short delay before new keys are used for dispatch.
+::::
+
+## Bulk actions
+
+On the action policies list, select one or more policies to enable, disable, snooze, and do more in bulk. **Select all** selects every policy on the current page of results. Clear the selection before changing filters if you need a different set.
diff --git a/explore-analyze/alerting/kibana-alerting-v2/quick-start-alerting-v2.md b/explore-analyze/alerting/kibana-alerting-v2/quick-start-alerting-v2.md
new file mode 100644
index 0000000000..ce67a535a4
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/quick-start-alerting-v2.md
@@ -0,0 +1,160 @@
+---
+navigation_title: Quick start
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+ - id: cloud-serverless
+description: "Create your first {{alerting-v2}} rule: enable the feature, write an {{esql}} query in the YAML editor, and confirm the rule is running by querying the rule events data stream."
+---
+
+# Quick start: Your first rule [alerting-quick-start-v2]
+
+$$$alerting-quick-start-v2$$$
+
+This tutorial walks you through the core {{alerting-v2}} model in action. You'll load sample error logs, create a rule that groups results by service, watch episodes open as the rule finds breaches, and then trigger recovery by deleting the data. By the end, you'll have learned about rules, grouping, episodes, and the alert lifecycle play out from start to finish.
+
+## Step 1: Create a sample data stream
+
+Run this in Dev Tools to create a data stream called `logs-tutorial` and populate it with sample error logs. This is the data your rule will query.
+
+```json
+POST logs-tutorial/_bulk
+{ "index": {} }
+{ "@timestamp": "2026-04-21T21:50:00.000Z", "log_level": "ERROR", "service_name": "checkout", "message": "Connection timeout" }
+{ "index": {} }
+{ "@timestamp": "2026-04-21T21:51:00.000Z", "log_level": "ERROR", "service_name": "checkout", "message": "Database query failed" }
+{ "index": {} }
+{ "@timestamp": "2026-04-21T21:52:00.000Z", "log_level": "ERROR", "service_name": "checkout", "message": "Null pointer exception" }
+{ "index": {} }
+{ "@timestamp": "2026-04-21T21:50:00.000Z", "log_level": "ERROR", "service_name": "payments", "message": "Payment gateway unreachable" }
+{ "index": {} }
+{ "@timestamp": "2026-04-21T21:51:00.000Z", "log_level": "ERROR", "service_name": "payments", "message": "Transaction rollback failed" }
+{ "index": {} }
+{ "@timestamp": "2026-04-21T21:50:00.000Z", "log_level": "INFO", "service_name": "checkout", "message": "Request received" }
+{ "index": {} }
+{ "@timestamp": "2026-04-21T21:51:00.000Z", "log_level": "INFO", "service_name": "payments", "message": "Health check passed" }
+```
+
+:::{note}
+`logs-tutorial` is automatically created as a data stream because the `logs-*` naming pattern matches Elasticsearch's default index template. You don't need to create it manually beforehand.
+:::
+
+Confirm the data was indexed. You should see `errors: false` and `result: "created"` for each document in the response.
+
+
+## Step 2: Verify the data is queryable
+
+Run this in Dev Tools to confirm the rule will find it:
+
+```esql
+FROM logs-tutorial
+| WHERE log_level == "ERROR"
+| STATS error_count = COUNT() BY service_name
+| WHERE error_count >= 2
+```
+
+You should see two rows: one for `checkout` (3 errors) and one for `payments` (2 errors). If you see this, the rule will trigger for both services.
+
+## Step 3: Create the rule
+
+Go to **Management > V2 Alerting Preview** and create a new rule using the YAML editor with the following configuration:
+
+
+
+```yaml
+kind: alert
+metadata:
+ name: tutorial-error-rate
+ tags:
+ - tutorial
+time_field: '@timestamp'
+schedule:
+ every: 5s
+ lookback: 24h
+evaluation:
+ query:
+ base: |-
+ FROM logs-tutorial
+ | WHERE log_level == "ERROR"
+ | STATS error_count = COUNT() BY service_name
+ | WHERE error_count >= 2
+grouping:
+ fields:
+ - service_name
+```
+
+
+
+Save the rule. It will be enabled automatically.
+
+
+## Step 4: Confirm the rule is running
+
+Wait 5 seconds, then run the following in Discover using the ES|QL mode. Replace `` with the `tutorial-error-rate` rule ID.
+
+```esql
+FROM .rule-events
+| WHERE rule.id == ""
+| SORT @timestamp DESC
+| LIMIT 10
+```
+
+:::{tip}
+After saving the rule, open its details page. The rule ID is the string at the end of the browser URL.
+:::
+
+Check the following in the query results:
+
+| Field | What you should see |
+|---|---|
+| `@timestamp` | Recent timestamps updating every 5 seconds |
+| `status` | `breached` confirms the query is finding matches |
+| `episode.status` | `active` confirms episodes have opened for both services |
+| `data.service_name` | `checkout` and `payments` confirms grouping is working |
+
+
+## Step 5: Confirm two episodes are open
+
+In Discover, run:
+
+```esql
+FROM .rule-events
+| WHERE rule.id == ""
+| STATS latest = MAX(@timestamp) BY episode.id, episode.status, data.service_name
+| SORT latest DESC
+```
+
+You should see two rows: one episode for `checkout` and one for `payments`, both with `episode.status: active`.
+
+
+## Step 6: Trigger recovery
+
+Delete the test data to clear the breach condition. Run the following in Dev Tools:
+
+```json
+POST logs-tutorial/_delete_by_query
+{
+ "query": { "match_all": {} }
+}
+```
+
+Wait up to 5 seconds, then re-run the query from Step 5 in Discover. Both episodes should now show `episode.status: inactive`.
+
+## What you learned
+
+By completing this tutorial, you saw the core alerting v2 model in action end to end:
+
+- **Rules query your data on a schedule.** Your rule ran every 5 seconds, checking for services with 2 or more errors in the last 24 hours.
+- **Grouping creates independent series.** Because the rule grouped by `service_name`, `checkout` and `payments` were tracked separately. Each got its own episode.
+- **Episodes follow a lifecycle.** When the error logs existed, both episodes moved to `active`. When you deleted the logs, both recovered and moved to `inactive` automatically, no manual intervention required.
+- **Rule events are the underlying record.** Every evaluation wrote documents to `.rule-events`, giving you a full queryable history of what the rule found and when.
+
+## Next steps
+
+- **Add notifications:** Create a workflow and action policy to route alerts when an episode opens or recovers. Refer to [Notifications](notifications-v2.md).
+- **Use your own data:** Swap `logs-tutorial` for a real data source and update the breach condition to match your use case. Refer to [Author rules](rules/author-rules-v2.md) to learn more.
+- **Explore rule history in Discover:** Query `.rule-events` to track trends, compare episode durations, and identify which services breach most frequently. Refer to [Query alerts and signals in Discover](alerts/query-alerts-and-signals-in-discover-v2.md) to learn more.
\ No newline at end of file
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules-v2.md
new file mode 100644
index 0000000000..9aecb4479b
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules-v2.md
@@ -0,0 +1,40 @@
+---
+navigation_title: Rules
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "What {{alerting-v2}} rules are, how evaluation works, and how rules connect to alerts and notifications."
+---
+
+# {{alerting-v2}} rules
+
+A rule is where {{alerting-v2}} starts. It points {{kib}} at the data you care about, describes what counts as a problem in {{esql}}, and says how often to check. Alerts, action policies, and notifications all flow from what a rule detects.
+
+## What rules do [detection-and-notification-v2]
+
+$$$detection-and-notification-v2$$$
+
+On each run, a rule executes an {{esql}} query against your data. If the query finds a match and the rule is in Detect mode, it writes a _signal_, a point-in-time record that the condition was met. In Alert mode, it also maintains an _alert episode_ for each matched series, tracking state from first breach through recovery.
+
+When creating a rule, choose Detect mode to record and query results without alerting anyone, or Alert mode when you want to track issues and route notifications.
+
+## What rules don't do
+
+Rules only define *what* to detect. They don't control notifications, who gets notified, or when. That's the job of action policies — global objects, scoped to your space, that match episodes from any rule. A rule has no say in which policies pick it up.
+
+This separation means you can build and test a rule without anyone getting paged, update notification routing without touching the rule, and have multiple action policies respond to the same rule independently.
+
+% ## How rule history works
+
+% Rules never overwrite old data. Each evaluation appends rows to `.rule-events`, giving you a complete, queryable history of every time the condition was met, when it cleared, and what the data looked like.
+
+% When a rule groups by fields (for example `BY host.name`), each unique combination is its own series, identified by `group_hash`. An episode spans one lifecycle arc on a series from first breach through recovery, identified by `episode_id`.
+
+% You can query this history in Discover, build dashboards from it, or write follow-on rules that read `.rule-events` as a data source.
+
+## Next steps
+
+- **[Author rules](rules/author-rules-v2.md):** Write the {{esql}} query, choose Detect or Alert mode, and structure your data sources and conditions.
+- **[View and manage rules](rules/view-manage-rules-v2.md):** Enable, disable, clone, delete, and bulk-manage rules from the rules list.
\ No newline at end of file
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md
new file mode 100644
index 0000000000..97177049c4
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md
@@ -0,0 +1,89 @@
+---
+navigation_title: Author rules
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Learn how to write ES|QL queries for rules. Choose a rule mode, structure a base query and alert condition, set thresholds, and assign severity levels."
+---
+
+# Author {{alerting-v2}} rules [author-rules-v2]
+
+$$$author-rules-v2$$$
+
+Authoring a rule means deciding three things: what condition in your data counts as a problem, whether you want the rule to silently record matches or actively track issues through to resolution, and which fields to carry forward onto each alert event so you can route and triage effectively. Getting these decisions right in the query is what makes the difference between a rule that fires on everything and one that surfaces the problems that actually need attention.
+
+This page covers the query concepts behind a rule definition. For settings beyond the query (such as schedules, grouping, and lifecycle thresholds), refer to [Configure a rule](configure-a-rule-v2.md). Once you understand what goes into a rule, you can write one using the [rule builder](create-rule-from-rule-builder-v2.md), [YAML editor](create-rule-with-yaml-v2.md), or [a Discover session](create-rule-from-discover-v2.md).
+
+## Choose a rule mode
+
+Before creating the rule, decide what you want it to do:
+
+| Mode | What it does |
+| --- | --- |
+| Detect (`kind: signal`) | Records query matches as signals. No episodes, no notifications. Good for testing a query or building a data history without alerting anyone. |
+| Alert (`kind: alert`) | Records matches and maintains alert episodes with lifecycle states. Episodes appear on the **Alerts** page and can be matched by action policies for notifications. |
+
+You can switch a rule's mode after creation from the rule list or rule detail page.
+
+## The {{esql}} query [esql-query-structure]
+
+Every rule has two parts to its query: the base query and the alert conditions.
+
+### Base query (required)
+The main {{esql}} expression. It runs on every evaluation, selects data from `FROM`, shapes results with `STATS`, `WHERE`, `EVAL`, and controls which fields are stored with `KEEP`. The base query always runs, even when no breach occurs, which is what enables no-data detection and recovery.
+
+### Alert conditions (optional)
+A `WHERE` clause applied after the base query. Only rows that pass the alert condition are treated as breaches. Without an alert condition, every row returned by the base query is a breach.
+
+```esql
+-- Base query: compute average CPU per host
+FROM metrics-*
+| STATS avg_cpu = AVG(system.cpu.total.pct) BY host.name
+
+-- Alert condition: only rows above the threshold count as breaches
+WHERE avg_cpu > 0.9
+```
+
+The `KEEP` command controls which fields appear on each stored alert event. Only the fields you `KEEP` are available for policy matchers, grouping keys, and triage in the Alerts UI.
+
+## Data sources
+
+Use `FROM` to point the rule at the indices or data streams to read. The query itself defines the scope. There is no separate data source step.
+
+```esql
+FROM logs-checkout-service-*
+| WHERE http.response.status_code >= 500
+| STATS error_count = COUNT(*) BY service.name
+| KEEP service.name, error_count
+```
+
+The [{{esql}} reference](elasticsearch://reference/query-languages/esql.md) covers all available commands and processing functions.
+
+## Conditions and thresholds [conditions-and-thresholds]
+
+The alert condition in {{esql}} defines what counts as a breach in each evaluation.
+
+The activation and recovery thresholds on the rule are separate from the query. They control how many consecutive breaches must occur, or how long the condition must persist, before an episode becomes active or moves back to inactive. Those settings are in [Configure a rule](configure-a-rule-v2.md#activation-recovery-thresholds-v2).
+
+For how alert states connect to episodes, refer to [Alert lifecycle](../alerts-v2.md#alert-lifecycle-v2).
+
+## Severity levels [severity-levels]
+
+Severity is carried by convention as a field under `data.*`, for example `data.severity` or `data.priority`. Include it in your `KEEP` so it is available as a matcher field on action policies, for example `data.severity: "critical"` in a policy KQL matcher.
+
+There is no required severity field name or fixed value set. Use whatever convention your team aligns on, and reference those same field names in your action policies.
+
+
+
+## Next steps
+
+Once you understand the query structure, explore [{{esql}} query patterns](esql-query-patterns-v2.md) for advanced use cases including SLO burn rate queries, no-data detection, persistent breach detection, and unsupported operations.
+
+
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md
new file mode 100644
index 0000000000..f9953a4261
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md
@@ -0,0 +1,124 @@
+---
+navigation_title: Configure a rule
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Configure {{alerting-v2}} rules: mode, ES|QL, grouping, schedule, lookback, activation and recovery, no-data handling, tags, and evaluation."
+---
+
+# Configure a {{alerting-v2}} rule [rule-settings-v2]
+
+$$$rule-settings-v2$$$
+
+The {{esql}} query defines what a rule detects. The settings on this page determine whether it behaves correctly in production: how often it runs, how it groups related problems, when it opens and closes alerts, and what it does when data stops arriving.
+
+For query authoring, refer to [Author rules](author-rules-v2.md). For notification routing, refer to [Notifications](../notifications-v2.md).
+
+:::{note}
+Action policies are not configured on the rule form. You create them separately in the **Action policies** area and use KQL matchers to scope them to the episodes you want to route. The rule builder form does not link to policies.
+:::
+
+## Rule mode [rule-mode-v2]
+
+Choose a mode that matches how you want to use results:
+
+| Mode | Behavior |
+| --- | --- |
+| Detect | Signals only: the rule produces detections without alert lifecycle tracking or notifications. |
+| Alert | Lifecycle tracking and notifications: alerts move through states (pending, active, recovering, and so on), and you can attach action policies so episodes dispatch through workflows. |
+
+Several settings on this page apply only when the rule is in Alert mode (`kind: alert`).
+
+## {{esql}} query [esql-query-rule-v2]
+
+The rule's {{esql}} query defines what to evaluate. It has a base query and an optional alert condition. Together they drive which rows become alert events and how no-data behavior applies. See [{{esql}} query structure](author-rules-v2.md#esql-query-structure) for how those pieces interact with no-data behavior and `KEEP`.
+
+## Rule grouping [rule-grouping-v2]
+
+$$$rule-grouping-v2$$$
+
+Rule grouping splits alert event generation by one or more group key fields so that each unique combination of field values produces its own alert series. Each series has independent lifecycle tracking, recovery detection, and per-series snooze.
+
+Group key fields must align with the `BY` clause in your {{esql}} query's `STATS` command. See [Author rules](author-rules-v2.md) for query patterns.
+
+Note that rule grouping is separate from notification grouping on an action policy, which controls how episodes batch into messages.
+
+
+
+## Schedule and lookback [schedule-lookback-v2]
+
+$$$schedule-lookback-v2$$$
+
+The schedule and lookback settings control how often a rule runs and how far back it looks when evaluating data.
+
+### Execution interval
+
+The execution interval (`schedule.every`) determines how frequently the rule evaluates.
+
+{{kib}} enforces a minimum interval of 5 seconds and a maximum of 365 days for duration fields (including this one). Values outside that range are rejected.
+
+### Lookback window
+
+The lookback window (`schedule.lookback`) determines the time range that the {{esql}} query covers.
+
+The lookback must not exceed 365 days. If the lookback is shorter than the execution interval, evaluations can miss data between runs. Use a lookback at least as long as the execution interval unless you have a deliberate reason not to.
+
+## Activation and recovery thresholds [activation-recovery-thresholds-v2]
+
+$$$activation-recovery-thresholds-v2$$$
+
+Activation and recovery thresholds control when alerts transition between lifecycle states. They reduce noise from short spikes and from rapid flapping between active and recovered.
+
+These settings are only available for Alert-mode rules (`kind: alert`).
+
+### Activation thresholds
+
+Configure activation using count, timeframe, or both:
+
+| Field | Description |
+| --- | --- |
+| `pending_count` | Consecutive breaches required |
+| `pending_timeframe` | Minimum duration the condition must persist |
+| `pending_operator` | How to combine count and timeframe (`AND` or `OR`) |
+
+Each timeframe value must be between 5 seconds and 365 days.
+
+### Recovery thresholds
+
+| Field | Description |
+| --- | --- |
+| `recovering_count` | Consecutive recoveries required |
+| `recovering_timeframe` | Minimum duration for recovery |
+| `recovering_operator` | How to combine count and timeframe (`AND` or `OR`) |
+
+Time frame fields use the same 5 seconds to 365 days bounds as activation timeframes.
+
+## No-data handling [no-data-handling-v2]
+
+No-data handling controls what happens when a rule executes and the base query returns no results. Proper configuration prevents false recoveries and misleading `no_data` events when data sources stop reporting.
+
+### Behaviors
+
+Set `no_data.behavior` to one of the following values:
+
+| Behavior | Effect |
+| --- | --- |
+| `no_data` | Record a no-data event (default) |
+| `last_status` | Carry forward the previous status |
+| `recover` | Treat absence as recovery |
+
+These behaviors apply when the base query returns zero rows. They do not help when you want to *detect* that a specific host or data source has gone silent. That requires a different query approach. See [No-data detection](esql-query-patterns-v2.md#no-data-esql-query-v2) in the authoring guide for an {{esql}} pattern that surfaces silent sources as alert rows.
+
+## Tags and investigation guide [tags-investigation-v2]
+
+Alert-mode rules support two optional metadata fields:
+
+- **Tags**: Free-form labels for filtering and organization.
+- **Investigation guide**: A runbook stored with the rule so responders have context when an alert fires.
+
+## Evaluate rule output [evaluate-rule-output-v2]
+
+Before relying on a rule in production, evaluate it against recent data by running a preview. A full evaluation surfaces how many rows the query returns, how many alert events would be generated, sample alert event documents, and a histogram of matching row counts over time.
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-discover-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-discover-v2.md
new file mode 100644
index 0000000000..8e5c1eb229
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-discover-v2.md
@@ -0,0 +1,38 @@
+---
+navigation_title: Using Discover
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Turn an {{esql}} query in Discover into a {{alerting-v2}} rule with pre-filled evaluation and lookback."
+---
+
+# Create rules from Discover [create-rules-discover-v2]
+
+$$$create-rules-discover-v2$$$
+
+Create {{alerting-v2}} rules directly from Discover. When you build an {{esql}} query that surfaces interesting patterns, you can convert it into a rule without rewriting the query. For the full rule form including alert mode settings and YAML toggle, refer to [Create rules using the rule builder](create-rule-from-rule-builder-v2.md).
+
+## How it works [discover-rule-flow-v2]
+
+Starting a rule from Discover means your query is already tested and returns the shape you expect before the rule is ever saved. Instead of drafting a query in the rule builder and hoping it works, you iterate in Discover (where you can see real results immediately) and then create the rule when the query is ready.
+
+When you trigger rule creation from Discover, your {{esql}} query pre-fills the rule form. The rule creation form also shows a preview panel that reflects how your query partitions results into alert series. If your query uses a `BY` clause, the preview shows the series that would be evaluated on each run. This lets you verify grouping logic against live data before committing to a schedule.
+
+## Preview query results before creating the rule [preview-query-discover-v2]
+
+$$$preview-query-discover-v2$$$
+
+The query preview in the rule creation flow runs your {{esql}} query against current data and displays the resulting rows. Use this to:
+
+- **Confirm grouping**: Check that your `BY` clause produces the series you intend — for example, one distinct series per host or per service, not a single undifferentiated result.
+- **Catch unexpected output**: Verify that the query returns data in the right shape for the alert condition you plan to set. A query that returns zero rows or an unexpected field name will not behave as expected once the rule runs on a schedule.
+- **Refine before committing**: Edit the query in the preview panel and re-run it without leaving the rule creation form. Once the preview looks correct, proceed to fill in the remaining settings.
+
+
\ No newline at end of file
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-rule-builder-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-rule-builder-v2.md
new file mode 100644
index 0000000000..b8cdef747d
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-rule-builder-v2.md
@@ -0,0 +1,21 @@
+---
+navigation_title: Using the rule builder
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Create a rule with the interactive rule builder"
+---
+
+# Create rules using the rule builder [create-rules-rule-builder-v2]
+
+$$$create-rules-rule-builder-v2$$$
+$$$create-rules-ui-v2$$$
+
+The rule builder is the right starting point when you're creating a rule from scratch and want inline guidance through each setting. For a full description of what each setting does, refer to [Configure a rule](configure-a-rule-v2.md).
+
+If you already have a working query in Discover, you can [create a rule directly from there](create-rule-from-discover-v2.md) without re-entering it. If you're managing rules as code or need to version-control rule definitions, use the [YAML editor](create-rule-with-yaml-v2.md) instead.
+
+
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-with-yaml-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-with-yaml-v2.md
new file mode 100644
index 0000000000..86d5a7f2e4
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-with-yaml-v2.md
@@ -0,0 +1,22 @@
+---
+navigation_title: Using the YAML editor
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Define {{alerting-v2}} rules as YAML for version control, infrastructure-as-code, and bulk provisioning."
+---
+
+# Create rules using the YAML editor [create-rules-yaml-v2]
+
+$$$create-rules-yaml-v2$$$
+
+The YAML editor lets you define rules as text documents rather than filling in a form. Use it when you want to version-control rule definitions alongside your other configuration, manage rules through infrastructure-as-code tooling, copy or adapt a rule quickly without re-entering settings by hand, or provision many rules at once.
+
+If you're creating a rule from scratch and want guidance through each setting, the [rule builder](create-rule-from-rule-builder-v2.md) is the better starting point. If you have a query already working in Discover, you can [create a rule directly from there](create-rule-from-discover-v2.md).
+
+For the full list of supported YAML fields and their accepted values, refer to [YAML rule schema reference](yaml-rule-schema-reference-v2.md).
+
+
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/esql-query-patterns-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/esql-query-patterns-v2.md
new file mode 100644
index 0000000000..00d8fd7288
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/esql-query-patterns-v2.md
@@ -0,0 +1,160 @@
+---
+navigation_title: ES|QL query patterns
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Advanced {{esql}} query patterns for {{alerting-v2}} rules: SLO burn rate, no-data detection, persistent breach, and unsupported operations."
+---
+
+# {{esql}} query patterns for {{alerting-v2}} rules [esql-query-patterns-v2]
+
+$$$esql-query-patterns-v2$$$
+
+Some detection problems can't be expressed as a single metric compared to a fixed threshold. You might need to know whether an SLO is burning through its error budget across multiple time windows at once. Or whether a specific host has gone silent, rather than whether the query returned nothing. Or whether a condition has persisted continuously across consecutive time buckets rather than appearing once. These are structurally different problems that require different query shapes.
+
+Use this page when a basic `STATS ... WHERE` pattern isn't enough, or when the detection logic itself requires multi-window calculation, last-seen reasoning, or bucket-level persistence checks. If you're still learning how {{alerting-v2}} rules work, start with [Author rules](author-rules-v2.md) first.
+
+## Basic threshold query [threshold-query-v2]
+
+A threshold query evaluates one metric over one lookback window and fires if a value crosses a limit. It is the simplest rule shape: a `STATS` aggregation followed by a `WHERE` condition.
+
+```esql
+FROM logs-*
+| STATS
+ // Count only error responses; count all requests for the denominator
+ error_count = COUNT_IF(http.response.status_code >= 500),
+ total_count = COUNT(*)
+ BY service.name
+| EVAL error_rate = error_count / total_count // Compute the error rate as a fraction (0–1)
+| WHERE error_rate > 0.10 // Alert condition: services above 10% error rate are breaches
+| KEEP service.name, error_rate, error_count, total_count
+```
+
+One window, one aggregate, one threshold check. The result is either a breach or no breach for each series.
+
+## SLO burn rate query [slo-burn-rate-query-v2]
+
+An SLO burn rate query asks a different question than a basic threshold: are you consuming your error budget faster than you can afford to? Rather than checking a single metric at a fixed limit, it calculates error rates across multiple time windows simultaneously and returns a severity level.
+
+### Why multiple windows
+
+Checking both a short window (for example, 5 minutes) and a long window (for example, 1 hour) together filters out brief spikes that do not represent a real budget threat. CRITICAL fires only when *both* the short and long burn rates exceed the threshold. The two-window requirement is what separates a genuine budget emergency from a momentary blip.
+
+### Query structure
+
+A single {{esql}} query handles all window pairs at once using conditional aggregation:
+
+```esql
+FROM metrics-*
+| WHERE @timestamp >= NOW() - 3 days // Lookback must cover the longest window pair used below.
+ // Keep this value in sync with the rule's lookback setting.
+| STATS
+ // CRITICAL window pair: 5 min catches the fast signal, 1 hour confirms it's sustained
+ errors_5m = COUNT_IF(outcome == "failure" AND @timestamp >= NOW() - 5 minutes),
+ total_5m = COUNT_IF(@timestamp >= NOW() - 5 minutes),
+ errors_1h = COUNT_IF(outcome == "failure" AND @timestamp >= NOW() - 1 hour),
+ total_1h = COUNT_IF(@timestamp >= NOW() - 1 hour),
+ // HIGH window pair: 30 min fast signal, 6 hours sustained confirmation
+ errors_30m = COUNT_IF(outcome == "failure" AND @timestamp >= NOW() - 30 minutes),
+ total_30m = COUNT_IF(@timestamp >= NOW() - 30 minutes),
+ errors_6h = COUNT_IF(outcome == "failure" AND @timestamp >= NOW() - 6 hours),
+ total_6h = COUNT_IF(@timestamp >= NOW() - 6 hours)
+ BY slo.id // Each SLO is evaluated independently
+| EVAL
+ // Compute error rates (errors as a fraction of total requests) for each window
+ burn_5m = errors_5m / total_5m,
+ burn_1h = errors_1h / total_1h,
+ burn_30m = errors_30m / total_30m,
+ burn_6h = errors_6h / total_6h
+| EVAL severity = CASE(
+ // CRITICAL: both the fast and sustained windows exceed 14.4x the baseline error rate.
+ // Requiring both prevents a single brief spike from triggering a critical alert.
+ burn_5m > 14.4 AND burn_1h > 14.4, "CRITICAL",
+ // HIGH: same two-window logic at a lower threshold
+ burn_30m > 6.0 AND burn_6h > 6.0, "HIGH",
+ "none"
+ )
+| WHERE severity != "none" // Only breaching SLOs become alert rows
+| KEEP slo.id, severity, burn_5m, burn_1h, burn_30m, burn_6h // Store fields needed for routing and triage
+```
+
+The burn rate multipliers (14.4×, 6×) reflect standard SLO error budget consumption rates. Adjust them to match your SLO targets.
+
+Because the query computes several window pairs in one pass, the lookback window on the rule must cover the longest window in the query (3 days in the example above).
+
+
+
+
+
+## No-data detection [no-data-esql-query-v2]
+
+No-data detection inverts the normal pattern. Instead of filtering for data that meets a condition, you query for when data was *last seen* and flag sources that have gone silent.
+
+The technique uses a broad lookback to find all known hosts, then surfaces only those that have not reported recently:
+
+```esql
+FROM metrics-*
+| WHERE @timestamp >= NOW() - 12 hours // Broad lookback: must be wide enough that all known hosts
+ // have at least one event in the window under normal conditions
+| STATS last_seen = MAX(@timestamp) BY host.name // Find the most recent event timestamp per host
+| WHERE last_seen < NOW() - 15 minutes // Keep only hosts that have NOT reported in the last 15 minutes
+| KEEP host.name, last_seen // Each returned row is a silent host — the query result itself is the alert
+```
+
+Every row returned is a host that has gone silent, so the base query itself drives the alert. No separate alert condition is needed.
+
+### Variants
+
+| Variant | What it detects |
+|---|---|
+| Host-specific | Each host that stops reporting generates its own alert series (use `BY host.name` for grouping). |
+| Global | No data from any source. Omit the `BY` clause and check whether the query returns any rows at all. |
+| Combined | Flags both a high-metric condition *and* silent hosts in one query using a `CASE` expression to assign a `status` field (`"alert"`, `"no data"`, or `"ok"`), then filters to only the problematic rows. |
+
+### Lookback window sizing
+
+The lookback must be wide enough that known hosts appear in the result set. If the lookback is too short, a silent host falls outside the window and is never checked. However, large lookback windows on high-frequency data streams increase query cost significantly. Start with a lookback that comfortably covers the longest expected reporting gap for your hosts, not the full history of the index.
+
+For no-data behavior when the entire base query returns zero rows (as opposed to detecting specific silent sources), refer to [No-data handling](configure-a-rule-v2.md#no-data-handling-v2).
+
+
+
+## Limitations and workarounds [esql-limitations-v2]
+
+Some patterns from the classic alerting aggregation API are not directly available in {{esql}}, and some require workarounds.
+
+### Persistent breach detection [persistent-breach-v2]
+
+A persistent breach condition detects a metric that stays above a threshold across several consecutive time buckets (for example, "CPU above 90% in all 10 of the last 10 five-minute windows"). {{esql}} can express this with bucket counting:
+
+```esql
+FROM metrics-*
+| WHERE @timestamp >= NOW() - 50 minutes // Lookback must cover all 10 buckets (10 × 5 min = 50 min)
+| EVAL bucket = BUCKET(@timestamp, 5 minutes) // Assign each event to its 5-minute time bucket
+| STATS
+ total_buckets = COUNT_DISTINCT(bucket), // How many distinct buckets exist in the window
+ exceeding_buckets = COUNT_DISTINCT(
+ CASE(system.cpu.total.pct > 0.90, bucket, null) // Count only buckets where CPU exceeded the threshold;
+ ) // null values are excluded by COUNT_DISTINCT
+ BY host.name
+| WHERE total_buckets >= 10 // Require a full window of data before firing —
+ AND exceeding_buckets == total_buckets // guards against gaps making a partial breach look persistent;
+ // every bucket in the window must have breached
+| KEEP host.name, total_buckets, exceeding_buckets
+```
+
+The rule's lookback window must cover all the buckets you want to check (50 minutes for 10 five-minute buckets in this example). If any bucket is missing from the data because the host stopped reporting briefly mid-window, `total_buckets` drops below 10 and the condition does not fire. Design the query so that gaps in reporting produce the behavior you want: either treating partial coverage as a non-breach or adjusting the `WHERE` filter to allow it.
+
+
+
+### Derivative aggregation [derivative-aggregation-v2]
+
+{{esql}} does not have a `DERIVATIVE` function. In the {{es}} aggregations API, a derivative pipeline aggregation calculates the rate of change between consecutive time buckets (for example, "how fast is this counter increasing per minute?"). There is no equivalent in {{esql}} today.
+
+Use cases that require true per-bucket deltas (such as detecting a sudden acceleration in error rate) cannot be expressed as an {{esql}} rule at this time. Consider pre-computing deltas in an ingest pipeline or using a transform to write derived metrics to a separate index that your rule can then query with a standard threshold pattern.
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/rule-event-field-reference-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/rule-event-field-reference-v2.md
new file mode 100644
index 0000000000..e7f31bcb34
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/rule-event-field-reference-v2.md
@@ -0,0 +1,123 @@
+---
+navigation_title: Rule and event fields
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Reference for {{alerting-v2}} rule configuration fields and documents written to `.rule-events`."
+---
+
+# Rule event and field reference [rule-reference-v2]
+
+$$$rule-reference-v2$$$
+
+This page lists technical fields for rule configuration and rule event documents written to `.rule-events`. For alert actions in `.alert-actions`, refer to [Alert states and fields reference](../alerts/alert-states-and-fields-reference-v2.md#alert-states-reference-v2). For action policy dispatch outcomes, refer to [Action policy reference](../notifications/action-policy-reference-v2.md#action-policy-reference-v2).
+
+:::{important}
+The `.rule-events` and `.alert-actions` data streams are [system indices](/reference/glossary/index.md#glossary-system-index). {{kib}} manages their versioning, retention, and lifecycle through ILM. Older backing indices are deleted automatically when the retention window expires. Do not change mappings or index settings for these streams yourself.
+:::
+
+## Schedule and lookback
+
+These fields control when a rule runs and how far back its {{esql}} query looks on each evaluation.
+
+| Field | Description |
+|---|---|
+| `schedule.every` | Execution interval; minimum 5 seconds, maximum 365 days. |
+| `schedule.lookback` | Time range the {{esql}} query covers; must not exceed 365 days; should be at least `schedule.every` to avoid gaps. |
+
+## Activation thresholds
+
+These fields are only available in Alert mode. They control how many consecutive breaches, or how long a condition must persist, before an episode transitions from `pending` to `active`.
+
+| Field | Description |
+|---|---|
+| `pending_count` | Consecutive breaches required. |
+| `pending_timeframe` | Minimum duration the condition must persist. |
+| `pending_operator` | How to combine count and timeframe (`AND` or `OR`). |
+
+## Recovery thresholds
+
+These fields are only available in Alert mode. They control how many consecutive recoveries, or how long the condition must be clear, before an episode transitions from `recovering` to `inactive`.
+
+| Field | Description |
+|---|---|
+| `recovering_count` | Consecutive recoveries required. |
+| `recovering_timeframe` | Minimum duration for recovery. |
+| `recovering_operator` | How to combine count and timeframe (`AND` or `OR`). |
+
+## No-data handling
+
+These settings determine what the rule records when the {{esql}} query returns no rows on an evaluation.
+
+| Behavior | Effect |
+|---|---|
+| `no_data` (default) | Record a no-data event. |
+| `last_status` | Carry forward the previous status. |
+| `recover` | Treat absence as recovery. |
+
+## Rule grouping
+
+Grouping is configured in YAML. The fields listed here control how the rule partitions results into independent series, each with its own lifecycle.
+
+| Key | Description |
+|---|---|
+| `grouping.fields` | Array of field names; must align with `STATS ... BY` in the {{esql}} query. |
+
+
+
+## Rule event documents
+
+Each time a rule evaluates, {{kib}} writes one document per matched series to `.rule-events`. The `type` field determines the document kind:
+
+- **signal:** A point-in-time record that the query matched. Useful for querying history or chaining into follow-on rules. Signal documents do not include `episode.*` fields.
+- **alert:** A lifecycle-tracked episode visible in the alert inbox, episode details, and triage views. Alert documents include `episode.*` fields and represent a breach that stays open until the condition clears.
+
+Both kinds share the base fields below. Only `alert` documents add the [Episode fields](#episode-fields) listed further down.
+
+:::{note}
+`.rule-events` is a data stream, so it is append-only. A new document is written on every rule evaluation — existing documents are never updated. Each document is a snapshot of that moment: the `episode.status` field records the lifecycle stage the episode was in at that evaluation. To view the full history of an episode, query all documents that share the same `episode.id`. Refer to [Query alerts and signals in Discover](../alerts/query-alerts-and-signals-in-discover-v2.md#explore-alerts-discover-v2) for example queries.
+:::
+
+### Signal and alert fields
+
+These fields appear on all `.rule-events` documents, regardless of whether the rule is in Detect or Alert mode.
+
+| Field | Type | Required | Description |
+|---|---|---|---|
+| `@timestamp` | date | Yes | When this document was written to `.rule-events`. |
+| `scheduled_timestamp` | date | No | Scheduled execution time for this rule run. |
+| `rule.id` | keyword | Yes | Rule identifier. |
+| `rule.version` | long | Yes | Rule version at the time this event was emitted. |
+| `group_hash` | keyword | Yes | Series identity key for grouped evaluations. |
+| `data` | flattened | Yes | Payload from the {{esql}} query output. Shape depends on your rule. |
+| `status` | keyword | Yes | One of: `breached`, `recovered`, `no_data`. |
+| `source` | keyword | Yes | Origin of this event. Product-specific identifier. |
+| `type` | keyword | Yes | `signal` or `alert`. Application field on each rule event document written by {{kib}}. |
+
+
+
+:::{admonition} Fields not stored as a dedicated column
+There is no top-level or nested `duration` field on `.rule-events` documents. For triage or reporting, derive duration from [Query alerts and signals in Discover](../alerts/query-alerts-and-signals-in-discover-v2.md#explore-alerts-discover-v2), the alert UI, or your own queries over timestamps and episode identifiers.
+:::
+
+### Episode fields
+
+These fields only appear on documents with `type: alert`, written by rules running in Alert mode. They carry the lifecycle state for the episode associated with the matched series.
+
+| Field | Type | Description |
+|---|---|---|
+| `episode.id` | keyword | Episode identifier for this series. |
+| `episode.status` | keyword | One of: `inactive`, `pending`, `active`, `recovering`. |
+| `episode.status_count` | long | Count of consecutive evaluations in the current `episode.status`. Only set when `episode.status` is `pending` or `recovering`. |
+
+
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/view-manage-rules-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/view-manage-rules-v2.md
new file mode 100644
index 0000000000..189b22eadb
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/view-manage-rules-v2.md
@@ -0,0 +1,47 @@
+---
+navigation_title: View and manage rules
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Use the {{alerting-v2}} rules list and rule details page: filters, search, bulk actions, and what you find in rule conditions."
+---
+
+# View and manage {{alerting-v2}} rules [manage-rules-v2]
+
+$$$manage-rules-v2$$$
+
+$$$open-the-list$$$
+
+After a rule is created, edit its settings, pause it, remove it, and more from the page listing rules. The rules list gives you search, filter, sort, and bulk actions across all rules in the space. Selecting a rule name opens its details page, where you can review the full configuration and edit or act on it directly.
+
+## Find and filter rules [find-filter-rules-v2]
+
+$$$find-filter-rules-v2$$$
+
+Use the search bar at the top of the rules list to find rules by name. The search field accepts plain text and matches against rule names without requiring structured query syntax — type any part of a rule name to narrow the list. Combine text search with filter controls to narrow results further by rule type, status, or tags.
+
+Select any column header to sort the list. Use bulk actions when you need to enable, disable, or delete multiple rules at once.
+
+## Rule summary flyout [rule-summary-flyout-v2]
+
+$$$rule-summary-flyout-v2$$$
+
+To inspect a rule without navigating away from the rules list, select the expand icon on any row. The rule summary flyout opens alongside the list and shows a snapshot of the rule: its status, last run time, recent alert episode activity, and quick actions such as enable, disable, and snooze.
+
+Use the flyout when you want to confirm a rule is healthy or take a quick action without committing to a full page load. To open the complete rule configuration with all settings and edit controls, select the rule name in the table row or in the flyout header.
+
+## Rule details page
+
+- **Conditions**: The full {{esql}} base query, alert condition, schedule, lookback, grouping, and recovery settings.
+- **Runbook**: If the rule has an investigation guide, it appears here alongside Conditions.
+
+Use **Edit** to modify the rule, or the actions menu to enable, disable, clone, or delete it.
+
+## Disable versus snooze
+
+Use **Disable** when you want the rule to stop running entirely until you re-enable it. This is different from snoozing, which suppresses notifications or quiets a series or policy without stopping rule evaluation.
+
+- To snooze alert episodes or series, refer to [View, manage, and reference alerts](../alerts/view-and-manage-alerts-v2.md#alert-actions-v2).
+- To snooze or stop an action policy, refer to [Manage action policies](../notifications/manage-action-policies-v2.md).
diff --git a/explore-analyze/alerting/kibana-alerting-v2/rules/yaml-rule-schema-reference-v2.md b/explore-analyze/alerting/kibana-alerting-v2/rules/yaml-rule-schema-reference-v2.md
new file mode 100644
index 0000000000..eb7bf18e3c
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/rules/yaml-rule-schema-reference-v2.md
@@ -0,0 +1,109 @@
+---
+navigation_title: YAML rule schema reference
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+description: "Complete field reference for {{alerting-v2}} YAML rule definitions: required fields, metadata, schedule, grouping, state transitions, no-data handling, and duration format."
+---
+
+# YAML rule schema reference [yaml-rule-schema-reference-v2]
+
+$$$yaml-rule-schema-reference-v2$$$
+
+This page lists valid fieldS for YAML rule definitions. For examples and authoring guidance, refer to [Create rules using the YAML editor](create-rule-with-yaml-v2.md).
+
+## Required fields
+
+| Field | Type | Accepted values | Description |
+|---|---|---|---|
+| `kind` | string | `alert` or `signal` | Whether the rule tracks ongoing episodes (`alert`) or records point-in-time observations (`signal`). |
+| `metadata.name` | string | Max 256 characters | The name of the rule. |
+| `schedule.every` | duration | For example, `5s`, `1m`, `5m` | How often the rule runs. Minimum interval applies. |
+| `evaluation.query.base` | string | Valid {{esql}} query, max 10,000 characters | The query that checks your data on each run. |
+
+## Metadata fields
+
+| Field | Type | Accepted values | Description |
+|---|---|---|---|
+| `metadata.description` | string | Max 1,024 characters | Optional description of what the rule monitors. |
+| `metadata.owner` | string | Max 256 characters | Team or person responsible for the rule. |
+| `metadata.tags` | array of strings | Max 100 tags | Labels for filtering and organization. |
+
+## Schedule fields
+
+| Field | Type | Accepted values | Description |
+|---|---|---|---|
+| `schedule.lookback` | duration | For example, `5m`, `24h` | How far back in time the query searches on each run. |
+| `time_field` | string | Any valid field name, max 128 characters | The timestamp field used for the lookback window filter. Defaults to `@timestamp`. |
+
+## Recovery policy fields
+
+| Field | Type | Accepted values | Description |
+|---|---|---|---|
+| `recovery_policy.type` | string | `no_breach` or `query` | How recovery is detected. `no_breach` recovers when the query returns no results. `query` uses a separate recovery query. |
+| `recovery_policy.query.base` | string | Valid {{esql}} query | Required when `recovery_policy.type` is `query`. The query that checks whether the condition has cleared. |
+
+
+
+## State transition fields
+
+Only valid when `kind: alert`. Controls how many consecutive detections are required before an episode becomes active or recovers.
+
+| 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 | 0 or more | Number of consecutive breaches required before the episode becomes active. |
+| `state_transition.pending_timeframe` | duration | For example, `5m` | Time window within which the breach count must be met. |
+| `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 | 0 or more | Number of consecutive clear evaluations required before the episode recovers. |
+| `state_transition.recovering_timeframe` | duration | For example, `5m` | Time window within which the recovery count must be met. |
+
+## Grouping fields
+
+| Field | Type | Accepted values | Description |
+|---|---|---|---|
+| `grouping.fields` | array of strings | Max 16 fields, each max 256 characters | Fields to group results by. Each unique combination becomes its own series. |
+
+
+
+## No-data fields
+
+| Field | Type | Accepted values | Description |
+|---|---|---|---|
+| `no_data.behavior` | string | `no_data`, `last_status`, or `recover` | What happens when the query returns no results. `no_data` records a no-data event. `last_status` keeps the current status. `recover` closes any active episode. |
+| `no_data.timeframe` | duration | For example, `5m` | How long the query must return no results before the no-data behavior applies. |
+
+## Artifact fields
+
+| Field | Type | Accepted values | Description |
+|---|---|---|---|
+| `artifacts[].type` | string | For example, `runbook` | The type of artifact being attached. |
+| `artifacts[].value` | string | Markdown content | The content of the artifact. Runbooks are rendered as markdown in the rule detail view. |
+
+## Notification policy fields
+
+| Field | Type | Accepted values | Description |
+|---|---|---|---|
+| `notification_policies[].ref` | string | Format: `policies/` | Links a notification policy to the rule. |
+
+## Duration format
+
+All duration fields accept the following units:
+
+| Unit | Example | Meaning |
+|---|---|---|
+| `s` | `30s` | Seconds |
+| `m` | `5m` | Minutes |
+| `h` | `1h` | Hours |
+| `d` | `7d` | Days |
diff --git a/explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md b/explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md
new file mode 100644
index 0000000000..103e9eb504
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md
@@ -0,0 +1,68 @@
+---
+navigation_title: Set up
+applies_to:
+ stack: unavailable
+ serverless: preview
+products:
+ - id: kibana
+ - id: cloud-serverless
+description: "Get {{alerting-v2}} running in your space: enable the UI, confirm data streams, then understand spaces, API keys, and privileges."
+---
+
+# Set up {{alerting-v2}} [alerting-setup-v2]
+
+$$$alerting-setup-v2$$$
+
+Before you can create your first rule, {{alerting-v2}} needs to be enabled in your space and a few background systems need to be in place. Rules rely on two data streams to store their output, API keys to run with the right privileges, and space scoping to keep objects organized. Getting these right upfront means your rules will run cleanly and their output will be queryable from the start.
+
+If you want to jump straight to creating a rule, go to [Quick start](quick-start-alerting-v2.md). For privilege requirements, refer to [{{alerting-v2}} privileges](alerting-v2-privileges.md).
+
+## Enable {{alerting-v2}} [alerting-set-up-v2]
+
+$$$alerting-set-up-v2$$$
+
+{{alerting-v2}} is in experimental in {{stack}} 9.5 and in {{serverless-short}}.
+
+
+
+## Where rule events are stored
+
+{{alerting-v2}} automatically creates and manages two data streams when the first rule runs. You don't need to create them manually.
+
+| Data stream | What it stores |
+|---|---|
+| `.rule-events` | A record for every rule evaluation. One document per result row, per run. Never updated in place. |
+| `.alert-actions` | Records for acknowledge, snooze, deactivate, fire, suppress, and other audit and suppression tracking. |
+
+Both data streams are hidden system data streams. To query them in Discover, prefix the name with `$`:
+
+```esql
+FROM $`.rule-events`
+| WHERE rule.id == ""
+| SORT @timestamp DESC
+| LIMIT 10
+```
+
+
+
+After your first rule runs, use the query above in Discover to confirm documents are appearing. If nothing appears after a few seconds, check that the rule is enabled and that your ES|QL query returns results when run independently.
+
+## Spaces [spaces-for-alerting-v2]
+
+Rules and action policies are space-scoped. Objects you create in one space are not visible in another. Alert events are stored globally, but the UI filters what you see by space.
+
+## API keys [alerting-privileges-v2]
+
+$$$alerting-privileges-v2$$$
+
+Saving a rule or action policy automatically creates an API key that is used to run it. The key inherits the privileges of the user who saved the object. If those privileges change over time, update the key from the rule or policy management UI.
+
+## Next steps
+
+When you're ready to go further, these can be done in any order:
+
+- **[Author rules](rules/author-rules-v2.md):** Write the {{esql}} query that defines what to detect, choose Detect or Alert mode, and configure grouping and thresholds in [Configure a rule](rules/configure-a-rule-v2.md).
+- **[Set up workflows](workflows-alerting-v2.md):** Configure the automation objects that deliver messages — email, Slack, webhook, and so on. You need at least one workflow before action policies can send anything.
+- **[Create action policies](notifications/create-configure-action-policy-v2.md):** Define who gets notified, how often, and under what conditions. Policies use KQL matchers to pick up the right episodes and route them to your workflows.
\ No newline at end of file
diff --git a/explore-analyze/alerting/kibana-alerting-v2/workflows-alerting-v2.md b/explore-analyze/alerting/kibana-alerting-v2/workflows-alerting-v2.md
new file mode 100644
index 0000000000..f096645d27
--- /dev/null
+++ b/explore-analyze/alerting/kibana-alerting-v2/workflows-alerting-v2.md
@@ -0,0 +1,38 @@
+---
+navigation_title: Workflows
+applies_to:
+ stack: ga 9.4, preview 9.3
+ serverless: ga
+products:
+ - id: kibana
+description: "How workflows connect to {{alerting-v2}} action policies and rule automation, and where to configure them."
+---
+
+# Workflows for {{alerting-v2}} [workflows-v2]
+
+$$$workflows-v2$$$
+
+Without a workflow, an action policy has nowhere to send notifications. [Workflows](../../workflows.md) are the delivery layer. They define the actual steps that run when a policy matches an episode: sending a message, calling a webhook, triggering automation, or any combination. Setting up a workflow is what connects {{alerting-v2}} to the tools your team already uses for incident response.
+
+Before creating an action policy, make sure the workflows you want to use already exist in your space. Policies store references to workflow IDs, so a destination workflow must exist before you can select it.
+
+::::{note}
+Only manual triggers are supported for workflows used with action policies.
+::::
+
+## Runtime execution order [runtime-execution-order]
+
+After a rule produces or updates alert episodes, processing follows this sequence:
+
+```
+Rule → Alert → Action Policy → Workflow → Notification
+```
+
+1. The rule runs its {{esql}} evaluation and writes to `.rule-events`.
+2. In Alert mode, alert documents and episodes represent the ongoing issue.
+3. Action policies in the same space are evaluated against episodes (matcher, suppression, grouping, frequency).
+4. For each dispatch, the policy invokes its configured workflows.
+5. Notifications are the outcome: Email, chat, webhook, and so on.
+
+The policy evaluates matchers and **frequency** limits before any workflow step runs, even though you created the workflow before the policy. That's why configuration order (workflow first, then policy, then rule) is the reverse of runtime order.
+
diff --git a/explore-analyze/alerting/watcher.md b/explore-analyze/alerting/watcher.md
index a90e3a4787..c1a67df629 100644
--- a/explore-analyze/alerting/watcher.md
+++ b/explore-analyze/alerting/watcher.md
@@ -17,7 +17,7 @@ products:
# {{watcher}}
::::{tip}
-{{kib}} Alerting provides a set of built-in actions and alerts that are integrated with applications such as APM, Metrics, Security, and Uptime. You can use {{kib}} Alerting to detect complex conditions within different {{kib}} apps and trigger actions when those conditions are met. For more information, refer to [Alerting](../alerting.md).
+{{kib}} Alerting provides a set of built-in actions and alerts that are integrated with applications such as APM, Metrics, Security, and Uptime. You can use {{kib}} Alerting to detect complex conditions within different {{kib}} apps and trigger actions when those conditions are met. For more information, refer to [Alerting](../alerting-overview.md).
::::
You can use {{watcher}} to watch for changes or anomalies in your data and perform the necessary actions in response. For example, you might want to:
diff --git a/explore-analyze/alerting/watcher/enable-watcher.md b/explore-analyze/alerting/watcher/enable-watcher.md
index e4ca04d971..18950bd57b 100644
--- a/explore-analyze/alerting/watcher/enable-watcher.md
+++ b/explore-analyze/alerting/watcher/enable-watcher.md
@@ -10,7 +10,7 @@ products:
# Enable Watcher [enable-watcher]
::::{note}
-If you are looking for Kibana alerting, check [Alerting](../../../explore-analyze/alerting.md).
+If you are looking for Kibana alerting, check [Alerting](../../../explore-analyze/alerting-overview.md).
::::
Watcher can be enabled when configuring your cluster. You can run Alerting on a separate cluster from the cluster whose data you are actually watching.
@@ -23,7 +23,7 @@ To enable Watcher on a cluster, you may first need to perform one or several of
* To receive default Elasticsearch Watcher alerts (cluster status, nodes changed, version mismatch), you need to have monitoring enabled to send to the Admin email address specified in Kibana. To enable this, go to **Advanced Settings > Admin email**.
-To learn more about Kibana alerting and how to use it, check [Alerting and Actions](../../../explore-analyze/alerting.md).
+To learn more about Kibana alerting and how to use it, check [Alerting and Actions](../../../explore-analyze/alerting-overview.md).
## Send alerts by email [watcher-allowlist]
diff --git a/explore-analyze/alerting/watcher/watcher-getting-started.md b/explore-analyze/alerting/watcher/watcher-getting-started.md
index ac503a4e3c..e2635e9fee 100644
--- a/explore-analyze/alerting/watcher/watcher-getting-started.md
+++ b/explore-analyze/alerting/watcher/watcher-getting-started.md
@@ -167,7 +167,7 @@ To enable users to create and manipulate watches, assign them the `watcher_admin
To allow users to view watches and the watch history, assign them the `watcher_user` security role. Watcher users cannot create or manipulate watches; they are only allowed to execute read-only watch operations.
-## Where to go next [next-steps]
+## What's next [next-steps]
* See [*How {{watcher}} works*](how-watcher-works.md) for more information about the anatomy of a watch and the watch lifecycle.
* See [*Example watches*](example-watches.md) for more examples of setting up a watch.
diff --git a/explore-analyze/cases/create-cases.md b/explore-analyze/cases/create-cases.md
index b9d4d644a1..40a8dc41c5 100644
--- a/explore-analyze/cases/create-cases.md
+++ b/explore-analyze/cases/create-cases.md
@@ -71,7 +71,7 @@ Set up email notifications to alert users when they're assigned to a case, so th
:::{tab-item} {{ecloud}}
-Add the email domains to the [notifications domain allowlist](/explore-analyze/alerting/alerts.md).
+Add the email domains to the [notifications domain allowlist](/explore-analyze/alerting/kibana-alerting-v1.md).
You do not need to configure an email connector or update {{kib}} user settings—the preconfigured Elastic-Cloud-SMTP connector is used by default.
diff --git a/explore-analyze/discover/discover-get-started.md b/explore-analyze/discover/discover-get-started.md
index 1fd9e00e6e..21bf939077 100644
--- a/explore-analyze/discover/discover-get-started.md
+++ b/explore-analyze/discover/discover-get-started.md
@@ -402,10 +402,10 @@ From **Discover**, you can create a rule to periodically check when data goes ab
The **Create rule** form is pre-filled with the latest query sent to {{es}}.
-3. [Configure your query](../alerting/alerts/rule-type-es-query.md) and [select a connector type](../../deploy-manage/manage-connectors.md).
+3. [Configure your query](../alerting/kibana-alerting-v1/rule-type-es-query-v1.md) and [select a connector type](../../deploy-manage/manage-connectors.md).
4. Click **Save**.
-For more about this and other rules provided in {{alert-features}}, go to [Alerting](../alerting/alerts.md).
+For more about this and other rules provided in {{alert-features}}, go to [Alerting](../alerting/kibana-alerting-v1.md).
## What’s next? [_whats_next_4]
diff --git a/explore-analyze/geospatial-analysis.md b/explore-analyze/geospatial-analysis.md
index 11f29f9b08..d3cebd2825 100644
--- a/explore-analyze/geospatial-analysis.md
+++ b/explore-analyze/geospatial-analysis.md
@@ -89,7 +89,7 @@ Put machine learning to work for you and find the data that should stand out wit
## Alerting [geospatial-alerting]
-Let your location data drive insights and action with [geographic alerts](alerting/alerts/geo-alerting.md). Commonly referred to as geo-fencing, track moving objects as they enter or exit a boundary to receive notifications through common business systems (email, Slack, Teams, PagerDuty, and more).
+Let your location data drive insights and action with [geographic alerts](alerting/kibana-alerting-v1/geo-alerting-v1.md). Commonly referred to as geo-fencing, track moving objects as they enter or exit a boundary to receive notifications through common business systems (email, Slack, Teams, PagerDuty, and more).
Interested in learning more? Follow [step-by-step instructions](visualize/maps/asset-tracking-tutorial.md) for setting up tracking containment alerts to monitor moving vehicles.
diff --git a/explore-analyze/images/alert-episode-example-with-activation-threshold.png b/explore-analyze/images/alert-episode-example-with-activation-threshold.png
new file mode 100644
index 0000000000..2ee4e33dec
Binary files /dev/null and b/explore-analyze/images/alert-episode-example-with-activation-threshold.png differ
diff --git a/explore-analyze/images/alert-episode-example-without-threshold.png b/explore-analyze/images/alert-episode-example-without-threshold.png
new file mode 100644
index 0000000000..300e4ff21d
Binary files /dev/null and b/explore-analyze/images/alert-episode-example-without-threshold.png differ
diff --git a/explore-analyze/images/rule-alert-mode-diagram.png b/explore-analyze/images/rule-alert-mode-diagram.png
new file mode 100644
index 0000000000..3c28586a7b
Binary files /dev/null and b/explore-analyze/images/rule-alert-mode-diagram.png differ
diff --git a/explore-analyze/images/rule-detect-mode-diagram.png b/explore-analyze/images/rule-detect-mode-diagram.png
new file mode 100644
index 0000000000..cf35161810
Binary files /dev/null and b/explore-analyze/images/rule-detect-mode-diagram.png differ
diff --git a/explore-analyze/kibana-data-exploration-learning-tutorial.md b/explore-analyze/kibana-data-exploration-learning-tutorial.md
index 393ce47c96..9236bf23de 100644
--- a/explore-analyze/kibana-data-exploration-learning-tutorial.md
+++ b/explore-analyze/kibana-data-exploration-learning-tutorial.md
@@ -759,7 +759,7 @@ You've completed the core workflow, from sample data to a shareable dashboard. H
: The sample web logs data includes `geo.src` and `geo.dest` fields. [Maps](visualize/maps.md) lets you visualize this data on interactive maps and add them to dashboards.
**Set up alerts**
-: Don't wait for problems to show up on a dashboard. [Create alerting rules](alerting/alerts/alerting-getting-started.md) to get notified when your data crosses a threshold.
+: Don't wait for problems to show up on a dashboard. [Create alerting rules](alerting/kibana-alerting-v1/alerting-getting-started-v1.md) to get notified when your data crosses a threshold.
**Try machine learning**
: Use {{ml}} to [detect anomalies](/explore-analyze/machine-learning/anomaly-detection/ml-getting-started.md) in time-series data, forecast trends, or categorize log messages. The sample data sets include pre-configured {{anomaly-jobs}} you can experiment with.
diff --git a/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md b/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md
index 5168dcccc9..0bceadabf5 100644
--- a/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md
+++ b/explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md
@@ -249,14 +249,14 @@ and the **Alerts** panel.
If necessary, you can snooze rules to prevent them from generating actions. For
more details, refer to
-[Snooze and disable rules](/explore-analyze/alerting/alerts/create-manage-rules.md#controlling-rules).
+[Snooze and disable rules](/explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md#controlling-rules).
## Action variables [action-variables]
The following variables are specific to the {{ml}} rule types. An asterisk (`*`)
marks the variables that you can use in actions related to recovered alerts.
-You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
### {{anomaly-detect-cap}} alert action variables [anomaly-alert-action-variables]
diff --git a/explore-analyze/query-filter/languages/esql-kibana.md b/explore-analyze/query-filter/languages/esql-kibana.md
index e74067083a..1759e4a69f 100644
--- a/explore-analyze/query-filter/languages/esql-kibana.md
+++ b/explore-analyze/query-filter/languages/esql-kibana.md
@@ -19,7 +19,7 @@ The {{esql}} editor is available in the following areas of {{kib}}:
- [**Discover**](/explore-analyze/discover/try-esql.md): Explore and analyze your data using {{esql}} queries, visualize results, and save your findings to dashboards.
- [**Dashboards**](/explore-analyze/dashboards.md): Create {{esql}}-powered visualization panels and interactive controls.
-- [**Alerting**](/explore-analyze/alerting/alerts/rule-type-es-query.md): Create alerting rules based on {{esql}} queries.
+- [**Alerting**](/explore-analyze/alerting/kibana-alerting-v1/rule-type-es-query-v1.md): Create alerting rules based on {{esql}} queries.
- [**{{elastic-sec}} solution**](/solutions/security/esql-for-security.md): Use {{esql}} for threat hunting, detection rules, and investigation workflows.
Find the complete list of supported commands, functions, and operators in the [{{esql}} reference](elasticsearch://reference/query-languages/esql/esql-syntax-reference.md).
diff --git a/explore-analyze/report-and-share/automating-report-generation.md b/explore-analyze/report-and-share/automating-report-generation.md
index 5ca533bae5..1e617ce3ec 100644
--- a/explore-analyze/report-and-share/automating-report-generation.md
+++ b/explore-analyze/report-and-share/automating-report-generation.md
@@ -226,7 +226,7 @@ Save time by setting up a recurring task that automatically generates reports an
notifications.connectors.default.email: my-email
```
-* (Optional) To control who can receive email notifications from {{kib}}, add the [`xpack.actions.email.domain_allowlist` setting](kibana://reference/configuration-reference/alerting-settings.md) to your `kibana.yml` file. To learn more about configuring this setting, refer to [Notifications domain allowlist](../alerting/alerts/notifications-domain-allowlist.md).
+* (Optional) To control who can receive email notifications from {{kib}}, add the [`xpack.actions.email.domain_allowlist` setting](kibana://reference/configuration-reference/alerting-settings.md) to your `kibana.yml` file. To learn more about configuring this setting, refer to [Notifications domain allowlist](../alerting/kibana-alerting-v1/notifications-domain-allowlist-v1.md).
### Create a schedule [create-scheduled-report]
@@ -253,7 +253,7 @@ Save time by setting up a recurring task that automatically generates reports an
* **Message**: Keep the default email message, or enter your own. To format and structure your message text, use Markdown.
::::{note}
- In the subject and message, you can also use the [Mustache](https://mustache.github.io/mustache.5.html) template syntax (`{{variable name}}`) to dynamically pass values from data sources when the email is generated. Enhancing the values passed by Mustache variables is also supported. Refer to [](../../explore-analyze/alerting/alerts/rule-action-variables.md#enhance-mustache-variables) to learn more.
+ In the subject and message, you can also use the [Mustache](https://mustache.github.io/mustache.5.html) template syntax (`{{variable name}}`) to dynamically pass values from data sources when the email is generated. Enhancing the values passed by Mustache variables is also supported. Refer to [](../../explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md#enhance-mustache-variables) to learn more.
::::
6. Click **Schedule exports** to save the schedule.
diff --git a/explore-analyze/toc.yml b/explore-analyze/toc.yml
index 2a57f93a92..d85a1c4412 100644
--- a/explore-analyze/toc.yml
+++ b/explore-analyze/toc.yml
@@ -378,28 +378,57 @@ toc:
children:
- file: report-and-share/reporting-troubleshooting-csv.md
- file: report-and-share/reporting-troubleshooting-pdf.md
- - file: alerting.md
+ - file: alerting-overview.md
children:
- - file: alerting/alerts.md
+ - file: alerting/choose-an-alerting-system.md
+ - file: alerting/kibana-alerting-v1.md
children:
- - file: alerting/alerts/alerting-getting-started.md
- - file: alerting/alerts/alerting-setup.md
- - file: alerting/alerts/create-manage-rules.md
- - file: alerting/alerts/view-alerts.md
- - file: alerting/alerts/query-alerts.md
- - file: alerting/alerts/rule-types.md
- children:
- - file: alerting/alerts/rule-type-index-threshold.md
- - file: alerting/alerts/rule-type-es-query.md
- - file: alerting/alerts/geo-alerting.md
- - file: alerting/alerts/rule-action-variables.md
- - file: alerting/alerts/notifications-domain-allowlist.md
- - file: alerting/alerts/alerting-troubleshooting.md
- children:
- - file: alerting/alerts/alerting-common-issues.md
- - file: alerting/alerts/event-log-index.md
- - file: alerting/alerts/testing-connectors.md
- - file: alerting/alerts/maintenance-windows.md
+ - file: alerting/kibana-alerting-v1/alerting-getting-started-v1.md
+ - file: alerting/kibana-alerting-v1/alerting-setup-v1.md
+ - file: alerting/kibana-alerting-v1/create-manage-rules-v1.md
+ - file: alerting/kibana-alerting-v1/view-alerts-v1.md
+ - file: alerting/kibana-alerting-v1/query-alerts-v1.md
+ - file: alerting/kibana-alerting-v1/rule-types-v1.md
+ children:
+ - file: alerting/kibana-alerting-v1/rule-type-index-threshold-v1.md
+ - file: alerting/kibana-alerting-v1/rule-type-es-query-v1.md
+ - file: alerting/kibana-alerting-v1/geo-alerting-v1.md
+ - file: alerting/kibana-alerting-v1/rule-action-variables-v1.md
+ - file: alerting/kibana-alerting-v1/notifications-domain-allowlist-v1.md
+ - file: alerting/kibana-alerting-v1/alerting-troubleshooting-v1.md
+ children:
+ - file: alerting/kibana-alerting-v1/alerting-common-issues-v1.md
+ - file: alerting/kibana-alerting-v1/event-log-index-v1.md
+ - file: alerting/kibana-alerting-v1/testing-connectors-v1.md
+ - file: alerting/kibana-alerting-v1/maintenance-windows-v1.md
+ - file: alerting/kibana-alerting-v2.md
+ children:
+ - file: alerting/kibana-alerting-v2/quick-start-alerting-v2.md
+ - file: alerting/kibana-alerting-v2/setup-alerting-v2.md
+ - file: alerting/kibana-alerting-v2/alerting-v2-privileges.md
+ - file: alerting/kibana-alerting-v2/rules-v2.md
+ children:
+ - file: alerting/kibana-alerting-v2/rules/author-rules-v2.md
+ - file: alerting/kibana-alerting-v2/rules/esql-query-patterns-v2.md
+ - file: alerting/kibana-alerting-v2/rules/create-rule-from-rule-builder-v2.md
+ - file: alerting/kibana-alerting-v2/rules/create-rule-from-discover-v2.md
+ - file: alerting/kibana-alerting-v2/rules/create-rule-with-yaml-v2.md
+ children:
+ - file: alerting/kibana-alerting-v2/rules/yaml-rule-schema-reference-v2.md
+ - file: alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md
+ - file: alerting/kibana-alerting-v2/rules/view-manage-rules-v2.md
+ - file: alerting/kibana-alerting-v2/rules/rule-event-field-reference-v2.md
+ - file: alerting/kibana-alerting-v2/alerts-v2.md
+ children:
+ - file: alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md
+ - file: alerting/kibana-alerting-v2/alerts/alert-states-and-fields-reference-v2.md
+ - file: alerting/kibana-alerting-v2/alerts/query-alerts-and-signals-in-discover-v2.md
+ - file: alerting/kibana-alerting-v2/workflows-alerting-v2.md
+ - file: alerting/kibana-alerting-v2/notifications-v2.md
+ children:
+ - file: alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md
+ - file: alerting/kibana-alerting-v2/notifications/action-policy-reference-v2.md
+ - file: alerting/kibana-alerting-v2/notifications/manage-action-policies-v2.md
- file: alerting/watcher.md
children:
- file: alerting/watcher/watcher-getting-started.md
diff --git a/explore-analyze/track-and-respond.md b/explore-analyze/track-and-respond.md
index 4a537b5331..390f4ebd6f 100644
--- a/explore-analyze/track-and-respond.md
+++ b/explore-analyze/track-and-respond.md
@@ -29,7 +29,7 @@ The {{es}} platform provides tools to share insights, get notified about importa
## Get notified when it matters with alerting
-[Alerting](alerting.md) monitors your {{es}} data continuously and notifies you when specific conditions are met, so you don't have to watch dashboards around the clock.
+[Alerting](alerting-overview.md) monitors your {{es}} data continuously and notifies you when specific conditions are met, so you don't have to watch dashboards around the clock.
:::{image} /explore-analyze/images/kibana-create-threshold-alert-created.png
:alt: Creating a threshold alert rule in Kibana
@@ -48,7 +48,7 @@ Elastic solutions extend this foundation with domain-specific rules. Security de
Alerts can also trigger [workflows](/explore-analyze/workflows.md) to automate multi-step responses, such as enriching an alert with context, creating a case, or notifying the on-call team.
-[Learn more about alerting →](alerting.md)
+[Learn more about alerting →](alerting-overview.md)
## Track and coordinate response with cases
@@ -81,5 +81,5 @@ For more complex scenarios, [workflows](/explore-analyze/workflows.md) can autom
## Next steps
- **[Automatically generate reports](report-and-share/automating-report-generation.md)**: Set up recurring report delivery for your dashboards.
-- **[Getting started with alerting](alerting/alerts/alerting-getting-started.md)**: Create your first alert rule and configure notification channels.
+- **[Getting started with alerting](alerting/kibana-alerting-v1/alerting-getting-started-v1.md)**: Create your first alert rule and configure notification channels.
- **[Create a case](cases/create-cases.md)**: Start tracking an incident and attach relevant alerts and evidence.
diff --git a/explore-analyze/transforms/transform-alerts.md b/explore-analyze/transforms/transform-alerts.md
index ced21c8f00..e34fd26360 100644
--- a/explore-analyze/transforms/transform-alerts.md
+++ b/explore-analyze/transforms/transform-alerts.md
@@ -10,7 +10,7 @@ products:
# Generating alerts for transforms [transform-alerts]
-{{kib}} {{alert-features}} include support for transform health rules, which check the health of {{ctransforms}} with certain conditions. If the conditions of the rule are met, an alert is created and the associated actions run. For example, you can create a rule to check if a {{ctransform}} is started and to notify you in an email if it is not. To learn more about {{kib}} {{alert-features}}, refer to [Alerting](../alerting/alerts/alerting-getting-started.md).
+{{kib}} {{alert-features}} include support for transform health rules, which check the health of {{ctransforms}} with certain conditions. If the conditions of the rule are met, an alert is created and the associated actions run. For example, you can create a rule to check if a {{ctransform}} is started and to notify you in an email if it is not. To learn more about {{kib}} {{alert-features}}, refer to [Alerting](../alerting/kibana-alerting-v1/alerting-getting-started-v1.md).
## Creating a rule [creating-transform-rules]
@@ -75,7 +75,7 @@ The name of an alert is always the same as the transform ID of the associated tr
## Action variables [transform-action-variables]
-The following variables are specific to the transform health rule type. You can also specify [variables common to all rules](../alerting/alerts/rule-action-variables.md).
+The following variables are specific to the transform health rule type. You can also specify [variables common to all rules](../alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.message`
: A preconstructed message for the rule. For example: `Transform test-1 is not started.`
@@ -104,4 +104,4 @@ The following variables are specific to the transform health rule type. You can
{{/context.results}}
```
-For more examples, refer to [Rule action variables](../alerting/alerts/rule-action-variables.md).
+For more examples, refer to [Rule action variables](../alerting/kibana-alerting-v1/rule-action-variables-v1.md).
diff --git a/explore-analyze/visualize/_snippets/emoji-table-esql.md b/explore-analyze/visualize/_snippets/emoji-table-esql.md
index 3222d27a1d..7481f71156 100644
--- a/explore-analyze/visualize/_snippets/emoji-table-esql.md
+++ b/explore-analyze/visualize/_snippets/emoji-table-esql.md
@@ -55,4 +55,4 @@ To create the visualization:
6. Optionally, once the panel is saved, select the panel title to give it a meaningful name like `Status per host`.
-Once you have your visualization working, you can add [controls](/explore-analyze/dashboards/add-controls.md#add-variable-control) to filter by host or time range, use [LOOKUP JOIN](elasticsearch://reference/query-languages/esql/esql-lookup-join.md) to enrich your data with metadata from other indices, or create [alerts](/explore-analyze/alerting/alerts/rule-type-es-query.md) based on the same query to get notified when status changes.
\ No newline at end of file
+Once you have your visualization working, you can add [controls](/explore-analyze/dashboards/add-controls.md#add-variable-control) to filter by host or time range, use [LOOKUP JOIN](elasticsearch://reference/query-languages/esql/esql-lookup-join.md) to enrich your data with metadata from other indices, or create [alerts](/explore-analyze/alerting/kibana-alerting-v1/rule-type-es-query-v1.md) based on the same query to get notified when status changes.
\ No newline at end of file
diff --git a/get-started/evaluate-elastic.md b/get-started/evaluate-elastic.md
index 2904c1a060..d513b641e9 100644
--- a/get-started/evaluate-elastic.md
+++ b/get-started/evaluate-elastic.md
@@ -307,7 +307,7 @@ For the second week, focus on the following activities:
- Add a few additional data sources relevant to your use case. Refer to [Fleet integrations](/reference/fleet/manage-integrations.md) for available integrations.
- Focus on metrics that demonstrate clear business value. Use [Lens visualizations](/explore-analyze/visualize/lens.md) to highlight KPIs.
-- Set up alerts for critical conditions or thresholds. Refer to [Alerting](/explore-analyze/alerting.md) for configuration options.
+- Set up alerts for critical conditions or thresholds. Refer to [Alerting](/explore-analyze/alerting-overview.md) for configuration options.
- Create dashboards that answer key stakeholder questions. Refer to [Create a dashboard](/explore-analyze/dashboards/create-dashboard.md) for guidance.
- Compare results against your success criteria.
- Quantify time savings, efficiency gains, or risk reduction.
diff --git a/get-started/the-stack.md b/get-started/the-stack.md
index 9e51eba81d..1c6cc379fa 100644
--- a/get-started/the-stack.md
+++ b/get-started/the-stack.md
@@ -83,7 +83,7 @@ With {{kib}}, you can:
- Build custom [visualizations](/explore-analyze/visualize.md) like charts, graphs, and metrics with tools like **Lens**, which offers a drag-and-drop experience.
- Assemble your visualizations into interactive [dashboards](/explore-analyze/dashboards.md) to get a comprehensive overview of your information.
- Perform [geospatial analysis](/explore-analyze/geospatial-analysis.md) and add maps to your dashboards.
-- Configure notifications for significant data events and track incidents with [alerts and cases](/explore-analyze/alerting.md).
+- Configure notifications for significant data events and track incidents with [alerts and cases](/explore-analyze/alerting-overview.md).
- Manage resources such as processors, pipelines, data streams, trained models, and more.
Each solution or project type provides access to customized features in {{kib}} such as built-in dashboards and [AI assistants](/explore-analyze/ai-features/ai-chat-experiences/ai-assistant.md).
diff --git a/manage-data/data-store/data-streams/failure-store-recipes.md b/manage-data/data-store/data-streams/failure-store-recipes.md
index a224432cfc..d0c2de3949 100644
--- a/manage-data/data-store/data-streams/failure-store-recipes.md
+++ b/manage-data/data-store/data-streams/failure-store-recipes.md
@@ -307,7 +307,7 @@ Without tags in place it would not be as clear where in the pipeline the indexin
## Alerting on failed ingestion [failure-store-examples-alerting]
-Since failure stores can be searched like a normal data stream, we can use them as inputs to [alerting rules](../../../explore-analyze/alerting/alerts.md) in
+Since failure stores can be searched like a normal data stream, we can use them as inputs to [alerting rules](../../../explore-analyze/alerting/kibana-alerting-v1.md) in
{{kib}}. Here is a simple alerting example that is triggered when more than ten indexing failures have occurred in the last five minutes for a data stream:
:::::{stepper}
diff --git a/redirects.yml b/redirects.yml
index 9e8eafb893..6c615e2af6 100644
--- a/redirects.yml
+++ b/redirects.yml
@@ -748,9 +748,9 @@ redirects:
# Related to cases and alerting documentation restructuring
# Main pages
- 'explore-analyze/alerts-cases.md': 'explore-analyze/alerting.md'
+ 'explore-analyze/alerts-cases.md': 'explore-analyze/alerting-overview.md'
'explore-analyze/alerts-cases/cases.md': 'explore-analyze/cases.md'
- 'explore-analyze/alerts-cases/alerts.md': 'explore-analyze/alerting/alerts.md'
+ 'explore-analyze/alerts-cases/alerts.md': 'explore-analyze/alerting/kibana-alerting-v1.md'
'explore-analyze/alerts-cases/watcher.md': 'explore-analyze/alerting/watcher.md'
# Cases redirects
@@ -763,24 +763,60 @@ redirects:
'explore-analyze/cases/configure-case-access.md': 'explore-analyze/cases/control-case-access.md'
'explore-analyze/cases/find-share-cases.md': 'explore-analyze/cases/search-share-cases.md'
- # Alerts redirects
- 'explore-analyze/alerts-cases/alerts/alerting-getting-started.md': 'explore-analyze/alerting/alerts/alerting-getting-started.md'
- 'explore-analyze/alerts-cases/alerts/alerting-setup.md': 'explore-analyze/alerting/alerts/alerting-setup.md'
- 'explore-analyze/alerts-cases/alerts/create-manage-rules.md': 'explore-analyze/alerting/alerts/create-manage-rules.md'
- 'explore-analyze/alerts-cases/alerts/view-alerts.md': 'explore-analyze/alerting/alerts/view-alerts.md'
- 'explore-analyze/alerts-cases/alerts/query-alerts.md': 'explore-analyze/alerting/alerts/query-alerts.md'
- 'explore-analyze/alerts-cases/alerts/rule-types.md': 'explore-analyze/alerting/alerts/rule-types.md'
- 'explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md': 'explore-analyze/alerting/alerts/rule-type-index-threshold.md'
- 'explore-analyze/alerts-cases/alerts/rule-type-es-query.md': 'explore-analyze/alerting/alerts/rule-type-es-query.md'
- 'explore-analyze/alerts-cases/alerts/geo-alerting.md': 'explore-analyze/alerting/alerts/geo-alerting.md'
- 'explore-analyze/alerts-cases/alerts/rule-action-variables.md': 'explore-analyze/alerting/alerts/rule-action-variables.md'
- 'explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md': 'explore-analyze/alerting/alerts/notifications-domain-allowlist.md'
- 'explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md': 'explore-analyze/alerting/alerts/alerting-troubleshooting.md'
- 'explore-analyze/alerts-cases/alerts/alerting-common-issues.md': 'explore-analyze/alerting/alerts/alerting-common-issues.md'
- 'explore-analyze/alerts-cases/alerts/event-log-index.md': 'explore-analyze/alerting/alerts/event-log-index.md'
- 'explore-analyze/alerts-cases/alerts/testing-connectors.md': 'explore-analyze/alerting/alerts/testing-connectors.md'
- 'explore-analyze/alerts-cases/alerts/maintenance-windows.md': 'explore-analyze/alerting/alerts/maintenance-windows.md'
-
+ # Alerts redirects (alerts-cases → alerting/kibana-alerting-v1)
+ 'explore-analyze/alerts-cases/alerts/alerting-getting-started.md': 'explore-analyze/alerting/kibana-alerting-v1/alerting-getting-started-v1.md'
+ 'explore-analyze/alerts-cases/alerts/alerting-setup.md': 'explore-analyze/alerting/kibana-alerting-v1/alerting-setup-v1.md'
+ 'explore-analyze/alerts-cases/alerts/create-manage-rules.md': 'explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md'
+ 'explore-analyze/alerts-cases/alerts/view-alerts.md': 'explore-analyze/alerting/kibana-alerting-v1/view-alerts-v1.md'
+ 'explore-analyze/alerts-cases/alerts/query-alerts.md': 'explore-analyze/alerting/kibana-alerting-v1/query-alerts-v1.md'
+ 'explore-analyze/alerts-cases/alerts/rule-types.md': 'explore-analyze/alerting/kibana-alerting-v1/rule-types-v1.md'
+ 'explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md': 'explore-analyze/alerting/kibana-alerting-v1/rule-type-index-threshold-v1.md'
+ 'explore-analyze/alerts-cases/alerts/rule-type-es-query.md': 'explore-analyze/alerting/kibana-alerting-v1/rule-type-es-query-v1.md'
+ 'explore-analyze/alerts-cases/alerts/geo-alerting.md': 'explore-analyze/alerting/kibana-alerting-v1/geo-alerting-v1.md'
+ 'explore-analyze/alerts-cases/alerts/rule-action-variables.md': 'explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md'
+ 'explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md': 'explore-analyze/alerting/kibana-alerting-v1/notifications-domain-allowlist-v1.md'
+ 'explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md': 'explore-analyze/alerting/kibana-alerting-v1/alerting-troubleshooting-v1.md'
+ 'explore-analyze/alerts-cases/alerts/alerting-common-issues.md': 'explore-analyze/alerting/kibana-alerting-v1/alerting-common-issues-v1.md'
+ 'explore-analyze/alerts-cases/alerts/event-log-index.md': 'explore-analyze/alerting/kibana-alerting-v1/event-log-index-v1.md'
+ 'explore-analyze/alerts-cases/alerts/testing-connectors.md': 'explore-analyze/alerting/kibana-alerting-v1/testing-connectors-v1.md'
+ 'explore-analyze/alerts-cases/alerts/maintenance-windows.md': 'explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md'
+
+ # Alerting v1 restructure redirects (alerting/alerts → alerting/kibana-alerting-v1)
+ 'explore-analyze/alerting.md': 'explore-analyze/alerting-overview.md'
+ 'explore-analyze/alerting/alerts.md': 'explore-analyze/alerting/kibana-alerting-v1.md'
+ 'explore-analyze/alerting/alerts/alerting-getting-started.md': 'explore-analyze/alerting/kibana-alerting-v1/alerting-getting-started-v1.md'
+ 'explore-analyze/alerting/alerts/alerting-setup.md': 'explore-analyze/alerting/kibana-alerting-v1/alerting-setup-v1.md'
+ 'explore-analyze/alerting/alerts/create-manage-rules.md': 'explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md'
+ 'explore-analyze/alerting/alerts/view-alerts.md': 'explore-analyze/alerting/kibana-alerting-v1/view-alerts-v1.md'
+ 'explore-analyze/alerting/alerts/query-alerts.md': 'explore-analyze/alerting/kibana-alerting-v1/query-alerts-v1.md'
+ 'explore-analyze/alerting/alerts/rule-types.md': 'explore-analyze/alerting/kibana-alerting-v1/rule-types-v1.md'
+ 'explore-analyze/alerting/alerts/rule-type-index-threshold.md': 'explore-analyze/alerting/kibana-alerting-v1/rule-type-index-threshold-v1.md'
+ 'explore-analyze/alerting/alerts/rule-type-es-query.md': 'explore-analyze/alerting/kibana-alerting-v1/rule-type-es-query-v1.md'
+ 'explore-analyze/alerting/alerts/geo-alerting.md': 'explore-analyze/alerting/kibana-alerting-v1/geo-alerting-v1.md'
+ 'explore-analyze/alerting/alerts/rule-action-variables.md': 'explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md'
+ 'explore-analyze/alerting/alerts/notifications-domain-allowlist.md': 'explore-analyze/alerting/kibana-alerting-v1/notifications-domain-allowlist-v1.md'
+ 'explore-analyze/alerting/alerts/alerting-troubleshooting.md': 'explore-analyze/alerting/kibana-alerting-v1/alerting-troubleshooting-v1.md'
+ 'explore-analyze/alerting/alerts/alerting-common-issues.md': 'explore-analyze/alerting/kibana-alerting-v1/alerting-common-issues-v1.md'
+ 'explore-analyze/alerting/alerts/event-log-index.md': 'explore-analyze/alerting/kibana-alerting-v1/event-log-index-v1.md'
+ 'explore-analyze/alerting/alerts/testing-connectors.md': 'explore-analyze/alerting/kibana-alerting-v1/testing-connectors-v1.md'
+ 'explore-analyze/alerting/alerts/maintenance-windows.md': 'explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md'
+
+ # Mistaken path under alerting/ (author rules live under kibana-alerting-v2/)
+ 'explore-analyze/alerting/author-rules.md': 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+
+ # {{alerting-v2}}: authoring rules renamed to author-rules
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/authoring-rules.md': 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+
+ # {{alerting-v2}}: concepts page renamed (was how-v2-alerting-works.md)
+ 'explore-analyze/alerting/kibana-alerting-v2/how-v2-alerting-works.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/before-you-begin/how-v2-alerting-works.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2.md'
+
+ # {{alerting-v2}}: authoring rules moved under rules/
+ 'explore-analyze/alerting/kibana-alerting-v2/authoring-rules.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+
# Watcher redirects
'explore-analyze/alerts-cases/watcher/watcher-getting-started.md': 'explore-analyze/alerting/watcher/watcher-getting-started.md'
'explore-analyze/alerts-cases/watcher/how-watcher-works.md': 'explore-analyze/alerting/watcher/how-watcher-works.md'
@@ -860,6 +896,359 @@ redirects:
anchors:
'otel-integrations-hybrid-policies': 'agent-policies-multiple-integrations'
+ # Kibana alerting v2: view-manage-rules merged into manage-rules.md
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-rules/view-manage-rules-v2.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/view-manage-rules-v2.md'
+ anchors:
+ 'view-manage-rules-v2': 'manage-rules-v2'
+
+ # Kibana alerting v2: child pages merged into parent hubs
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-rules/snooze-disable-rules.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/view-manage-rules-v2.md'
+ anchors:
+ 'snooze-disable-rules-v2': 'manage-rules-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/before-you-begin/set-up.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ anchors:
+ 'alerting-set-up-v2': 'alerting-set-up-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/get-started/before-you-begin.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ anchors:
+ 'alerting-set-up-v2': 'alerting-set-up-v2'
+ 'alerting-before-you-begin-v2': 'alerting-setup-v2'
+ 'alerting-privileges-v2': 'alerting-privileges-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/get-started/quickstart.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ anchors:
+ 'alerting-set-up-v2': 'alerting-set-up-v2'
+
+ 'explore-analyze/alerting/kibana-alerting-v2/quickstart.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ anchors:
+ 'alerting-set-up-v2': 'alerting-set-up-v2'
+
+ 'explore-analyze/alerting/kibana-alerting-v2/before-you-begin.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ anchors:
+ 'alerting-before-you-begin-v2': 'alerting-setup-v2'
+ 'alerting-privileges-v2': 'alerting-privileges-v2'
+ 'alerting-set-up-v2': 'alerting-set-up-v2'
+
+ 'explore-analyze/alerting/kibana-alerting-v2/before-you-begin/core-v2-alerting-concepts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/before-you-begin/alerting-privileges.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-alerts/view-alerts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'view-alerts-v2': 'manage-alerts-v2'
+
+ # Kibana alerting v2: rule settings consolidated; notification policies renamed to action policies
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-types.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+ anchors:
+ 'rule-types-v2': 'author-rules-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/notification-policies.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md'
+ anchors:
+ 'notification-policies-v2': 'action-policies-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/notification-policies/create-manage-notification-policies.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ anchors:
+ 'create-manage-notification-policies-v2': 'create-manage-action-policies-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/notification-policies/how-notification-policies-are-evaluated.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md'
+ anchors:
+ 'how-notification-policies-evaluated-v2': 'how-action-policies-evaluated-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/action-policies.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md'
+ anchors:
+ 'action-policies-v2': 'action-policies-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/action-policies/create-manage-action-policies.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ anchors:
+ 'create-manage-action-policies-v2': 'create-manage-action-policies-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/action-policies/how-action-policies-are-evaluated.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md'
+ anchors:
+ 'how-action-policies-evaluated-v2': 'how-action-policies-evaluated-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/action-policies/matcher.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ anchors:
+ 'matcher-v2': 'matcher-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/action-policies/grouping.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ anchors:
+ 'reduce-noise-grouping-v2': 'reduce-noise-grouping-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/action-policies/throttle.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ anchors:
+ 'throttle-v2': 'throttle-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/schedule-and-lookback.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md'
+ anchors:
+ 'schedule-lookback-v2': 'schedule-lookback-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/activation-and-recovery-thresholds.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md'
+ anchors:
+ 'activation-recovery-thresholds-v2': 'activation-recovery-thresholds-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/no-data-handling.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md'
+ anchors:
+ 'no-data-handling-v2': 'no-data-handling-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/grouping.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md'
+ anchors:
+ 'rule-grouping-v2': 'rule-grouping-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/maintenance-windows.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/manage-action-policies-v2.md'
+ anchors:
+ 'maintenance-windows-v2': 'maintenance-windows-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-settings/workflows.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/workflows-alerting-v2.md'
+ anchors:
+ 'workflows-v2': 'workflows-v2'
+
+ # Kibana alerting v2: reduce-noise pages merged into rule settings, action policies, manage-alerts
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/matcher.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ anchors:
+ 'matcher-v2': 'matcher-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/grouping.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ anchors:
+ 'reduce-noise-grouping-v2': 'reduce-noise-grouping-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/throttle.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ anchors:
+ 'throttle-v2': 'throttle-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/activation-thresholds.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md'
+ anchors:
+ 'activation-thresholds-v2': 'activation-recovery-thresholds-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/recovery-thresholds.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md'
+ anchors:
+ 'recovery-thresholds-v2': 'activation-recovery-thresholds-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/no-data-handling.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2.md'
+ anchors:
+ 'reduce-noise-no-data-v2': 'no-data-handling-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/maintenance-windows.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/manage-action-policies-v2.md'
+ anchors:
+ 'maintenance-windows-v2': 'maintenance-windows-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/snooze-or-silence.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'snooze-or-silence-v2': 'alert-actions-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-alerts/snooze-or-silence.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'snooze-or-silence-v2': 'alert-actions-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/deactivate-alerts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'deactivate-alerts-v2': 'alert-actions-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-alerts/deactivate-alerts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'deactivate-alerts-v2': 'alert-actions-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-alerts/investigate-respond/alert-actions.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'alert-actions-v2': 'alert-actions-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-alerts/investigate-respond/alert-episode-details.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'alert-episode-details-v2': 'alert-episode-details-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise/rules-on-alerts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+ anchors:
+ 'reduce-noise-rules-on-alerts-v2': 'author-rules-v2'
+
+ # Kibana alerting v2: author-rules pages folded into author-rules.md / rule-settings.md
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/set-rule-data-sources.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+ anchors:
+ 'set-rule-data-sources-v2': 'author-rules-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rules-on-alerts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+ anchors:
+ 'rules-on-alerts-v2': 'author-rules-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/production-considerations.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+ anchors:
+ 'production-considerations-v2': 'author-rules-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules/rule-templates.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+
+ # Kibana alerting v2: IA restructure (paths removed April 2026)
+ 'explore-analyze/alerting/kibana-alerting-v2/core-v2-alerting-concepts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2.md'
+ anchors:
+ 'kibana-alerting-v2-overview': 'kibana-alerting-v2-overview'
+ 'detection-and-notification-v2': 'detection-and-notification-v2'
+
+ # Kibana alerting v2: overview page merged into kibana-alerting-v2.md hub
+ 'explore-analyze/alerting/kibana-alerting-v2/overview.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2.md'
+ anchors:
+ 'kibana-alerting-v2-overview': 'kibana-alerting-v2-overview'
+ 'detection-and-notification-v2': 'detection-and-notification-v2'
+ 'key-concepts-glossary': 'key-concepts-glossary'
+ 'how-pieces-fit-together': 'how-pieces-fit-together'
+ 'runtime-execution-order': 'runtime-execution-order'
+ 'configuration-order': 'configuration-order'
+
+ # Kibana alerting v2: overview folder merged into kibana-alerting-v2.md
+ 'explore-analyze/alerting/kibana-alerting-v2/overview/how-system-works.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2.md'
+ anchors:
+ 'kibana-alerting-v2-overview': 'kibana-alerting-v2-overview'
+ 'detection-and-notification-v2': 'detection-and-notification-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/overview/key-concepts-glossary.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2.md'
+ anchors:
+ 'key-concepts-glossary': 'key-concepts-glossary'
+ 'explore-analyze/alerting/kibana-alerting-v2/overview/how-pieces-fit-together.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2.md'
+ anchors:
+ 'how-pieces-fit-together': 'how-pieces-fit-together'
+ 'runtime-execution-order': 'runtime-execution-order'
+ 'configuration-order': 'configuration-order'
+ 'explore-analyze/alerting/kibana-alerting-v2/get-starting.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ anchors:
+ 'alerting-set-up-v2': 'alerting-set-up-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/alerting-privileges.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ anchors:
+ 'alerting-privileges-v2': 'alerting-privileges-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/author-rules.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+ anchors:
+ 'author-rules-v2': 'author-rules-v2'
+ 'esql-query-structure': 'esql-query-structure'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-rules.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/view-manage-rules-v2.md'
+ anchors:
+ 'manage-rules-v2': 'manage-rules-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-alerts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'manage-alerts-v2': 'manage-alerts-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-alerts/investigate-respond.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'investigate-respond-v2': 'investigate-respond-v2'
+ 'alert-actions-v2': 'alert-actions-v2'
+ 'alert-episode-details-v2': 'alert-episode-details-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/manage-alerts/explore-alerts-discover.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/query-alerts-and-signals-in-discover-v2.md'
+ anchors:
+ 'explore-alerts-discover-v2': 'explore-alerts-discover-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/send-notifications.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md'
+ anchors:
+ 'send-notifications-v2': 'how-action-policies-evaluated-v2'
+ 'action-policies-v2': 'action-policies-v2'
+ 'how-action-policies-evaluated-v2': 'how-action-policies-evaluated-v2'
+ 'matcher-v2': 'matcher-v2'
+ 'reduce-noise-grouping-v2': 'reduce-noise-grouping-v2'
+ 'throttle-v2': 'throttle-v2'
+ 'create-manage-action-policies-v2': 'create-manage-action-policies-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/notifications/how-action-policies-work.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/notifications/about-action-policies.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/notifications/configure-action-policy.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-action-policy.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications/create-configure-action-policy-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/about-rules.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/how-rules-work.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/write-a-rule.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2.md'
+ anchors:
+ 'author-rules-v2': 'author-rules-v2'
+ 'esql-query-structure': 'esql-query-structure'
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/create-rules-ui.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-rule-builder-v2.md'
+ anchors:
+ 'create-rules-ui-v2': 'create-rules-ui-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-ui.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-rule-builder-v2.md'
+ anchors:
+ 'create-rules-ui-v2': 'create-rules-ui-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/create-rules-discover.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-from-discover-v2.md'
+ anchors:
+ 'create-rules-discover-v2': 'create-rules-discover-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/create-rules-yaml.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/create-rule-with-yaml-v2.md'
+ anchors:
+ 'create-rules-yaml-v2': 'create-rules-yaml-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/rules/rule-reference.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/rule-event-field-reference-v2.md'
+ anchors:
+ 'rule-reference-v2': 'rule-reference-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/alerts/about-alerts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/alerts/alert-lifecycle.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts-v2.md'
+ anchors:
+ 'alert-lifecycle-v2': 'alert-lifecycle-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-manage-alerts.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'manage-alerts-v2': 'manage-alerts-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/alerts/investigate-respond.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
+ anchors:
+ 'investigate-respond-v2': 'investigate-respond-v2'
+ 'alert-actions-v2': 'alert-actions-v2'
+ 'alert-episode-details-v2': 'alert-episode-details-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/alerts/alert-states-reference.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/alerts/alert-states-and-fields-reference-v2.md'
+ anchors:
+ 'alert-states-reference-v2': 'alert-states-reference-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/reduce-noise.md': 'explore-analyze/alerting/kibana-alerting-v2.md'
+
+ # Kibana alerting v2: troubleshooting folder — no dedicated replacement page; send to hub
+ 'explore-analyze/alerting/kibana-alerting-v2/troubleshooting/rules-not-generating-alerts.md': 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/troubleshooting/notifications-not-sending.md': 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/troubleshooting/action-policy-not-triggering.md': 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/troubleshooting/workflow-not-executing.md': 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/troubleshooting/alert-not-closing-after-resolution.md': 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/troubleshooting/unexpected-alert-behavior.md': 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/troubleshooting/validation-checklist.md': 'explore-analyze/alerting/kibana-alerting-v2.md'
+ 'explore-analyze/alerting/kibana-alerting-v2/troubleshooting/error-messages-reference.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/notifications-v2.md'
+ anchors:
+ 'error-messages-reference': 'possible-outcomes'
+ 'explore-analyze/alerting/kibana-alerting-v2/alert-event-field-reference.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/rules/rule-event-field-reference-v2.md'
+ anchors:
+ 'alert-event-field-reference-v2': 'rule-reference-v2'
+
+ # Agent Builder: skills concept renamed to custom agents and tools
+ 'explore-analyze/ai-features/agent-builder/agent-builder-dashboards-and-visualizations.md': 'explore-analyze/ai-features/agent-builder/chat.md'
+ 'explore-analyze/ai-features/agent-builder/builtin-skills-reference.md': 'explore-analyze/ai-features/agent-builder/builtin-agents-reference.md'
+ 'explore-analyze/ai-features/agent-builder/custom-skills.md': 'explore-analyze/ai-features/agent-builder/custom-agents.md'
+ 'explore-analyze/ai-features/agent-builder/skill-creation-guidelines.md': 'explore-analyze/ai-features/agent-builder/custom-agents.md'
+ 'explore-analyze/ai-features/agent-builder/skills.md': 'explore-analyze/ai-features/agent-builder/tools.md'
+
+ # Elastic Workflows: pages removed (use-cases subfolder deleted)
+ 'explore-analyze/workflows/get-started/build-your-first-workflow.md': 'explore-analyze/workflows/get-started.md'
+ 'explore-analyze/workflows/use-cases/ai-augmented-workflows.md': 'explore-analyze/workflows/use-cases.md'
+ 'explore-analyze/workflows/use-cases/observability.md': 'explore-analyze/workflows/use-cases.md'
+ 'explore-analyze/workflows/use-cases/security.md': 'explore-analyze/workflows/use-cases.md'
+ 'explore-analyze/workflows/use-cases/security/automate-security-operations.md': 'explore-analyze/workflows/use-cases.md'
+ 'explore-analyze/workflows/use-cases/security/manage-detection-rules.md': 'explore-analyze/workflows/use-cases.md'
+
# Workflows docset IA restructure (April 2026) — see explore-analyze/workflows/
# Note: no redirect for workflows/get-started.md because that URL is now occupied by a new parent
# index page. External links to the old tutorial land on the new parent, which links to the tutorial.
@@ -871,6 +1260,13 @@ redirects:
'explore-analyze/workflows/monitor-troubleshoot.md': 'explore-analyze/workflows/authoring-techniques/monitor-workflows.md'
'explore-analyze/workflows/manage-workflows.md': 'explore-analyze/workflows/authoring-techniques/manage-workflows.md'
'explore-analyze/workflows/authoring-techniques/migrate-from-9.3.md': 'explore-analyze/workflows/authoring-techniques/migrate-from-9-3.md'
+
+ # alerting-v2: pre-suffix rename redirects
+ 'explore-analyze/alerting/kibana-alerting-v2/get-started-v2.md':
+ to: 'explore-analyze/alerting/kibana-alerting-v2/setup-alerting-v2.md'
+ anchors:
+ 'alerting-get-started-v2': 'alerting-setup-v2'
+ 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-manage-and-reference-alerts-v2.md': 'explore-analyze/alerting/kibana-alerting-v2/alerts/view-and-manage-alerts-v2.md'
# Split off links for the EIS supported models page
'explore-analyze/elastic-inference/eis.md':
to: 'explore-analyze/elastic-inference/eis.md'
diff --git a/reference/fleet/alerting-rule-templates.md b/reference/fleet/alerting-rule-templates.md
index c1baa0208d..1b87b2f5d4 100644
--- a/reference/fleet/alerting-rule-templates.md
+++ b/reference/fleet/alerting-rule-templates.md
@@ -66,7 +66,7 @@ The preconfigured defaults include:
- **Alert delay (alert suppression)**
: The number of consecutive runs for which conditions must be met before an alert is created.
-For details about fields in the Create rule form and how the rule evaluates data, refer to the [{{es}} query rule type](/explore-analyze/alerting/alerts/rule-type-es-query.md).
+For details about fields in the Create rule form and how the rule evaluates data, refer to the [{{es}} query rule type](/explore-analyze/alerting/kibana-alerting-v1/rule-type-es-query-v1.md).
## Idle data streams template
diff --git a/reference/fleet/monitor-elastic-agent.md b/reference/fleet/monitor-elastic-agent.md
index 5c28f8b57f..794b138bb2 100644
--- a/reference/fleet/monitor-elastic-agent.md
+++ b/reference/fleet/monitor-elastic-agent.md
@@ -274,7 +274,7 @@ stack: ga 9.0-9.1
For versions 9.2.0 and later, {{agent}} includes out-of-the-box alert rules for the most common health checks. Check out [Elastic Agent built-in alerts](/reference/fleet/alert-templates.md).
:::
-You can access the health status of {{fleet}}-managed {{agents}} and other {{fleet}} settings through internal {{fleet}} indices. This enables you to leverage various applications within the {{stack}} that can be triggered by the provided information. For instance, you can now create alerts and machine learning (ML) jobs based on these specific fields. Refer to the [Alerting documentation](/explore-analyze/alerting.md) or see the [example](#fleet-alerting-example) on this page to learn how to define rules that can trigger actions when certain conditions are met.
+You can access the health status of {{fleet}}-managed {{agents}} and other {{fleet}} settings through internal {{fleet}} indices. This enables you to leverage various applications within the {{stack}} that can be triggered by the provided information. For instance, you can now create alerts and machine learning (ML) jobs based on these specific fields. Refer to the [Alerting documentation](/explore-analyze/alerting-overview.md) or see the [example](#fleet-alerting-example) on this page to learn how to define rules that can trigger actions when certain conditions are met.
This functionality allows you to effectively track an agent’s status, and identify scenarios where it has gone offline, is experiencing health issues, or is facing challenges related to input or output.
diff --git a/reference/glossary/index.md b/reference/glossary/index.md
index c501f6161e..2a1352e146 100644
--- a/reference/glossary/index.md
+++ b/reference/glossary/index.md
@@ -670,7 +670,7 @@ $$$glossary-rule$$$ rule
: A set of [conditions](/reference/glossary/index.md#glossary-condition), schedules, and [actions](/reference/glossary/index.md#glossary-action) that enable notifications. See [{{rules-ui}}](/reference/glossary/index.md#glossary-rules).
$$$glossary-rules$$$ Rules
-: A comprehensive view of all your alerting rules. Enables you to access and manage rules for all {{kib}} apps from one place. See [{{rules-ui}}](/explore-analyze/alerting.md).
+: A comprehensive view of all your alerting rules. Enables you to access and manage rules for all {{kib}} apps from one place. See [{{rules-ui}}](/explore-analyze/alerting-overview.md).
$$$glossary-runner$$$ runner
: A local control agent that runs on all hosts, used to deploy local containers based on role definitions. Ensures that containers assigned to it exist and are able to run, and creates or recreates the containers if necessary.
@@ -745,7 +745,7 @@ $$$glossary-split$$$ split
: Adds more [primary shards](/reference/glossary/index.md#glossary-primary-shard) to an [index](/reference/glossary/index.md#glossary-index).
$$$glossary-stack-alert$$$ stack rule
-: The general purpose rule types {{kib}} provides out of the box. Refer to [Stack rules](/explore-analyze/alerting/alerts/rule-types.md#stack-rules).
+: The general purpose rule types {{kib}} provides out of the box. Refer to [Stack rules](/explore-analyze/alerting/kibana-alerting-v1/rule-types-v1.md#stack-rules).
$$$glossary-standalone$$$ standalone
: This mode allows manual configuration and management of {{agent}}s locally on the systems where they are installed. See [Install standalone {{agent}}s](/reference/fleet/install-standalone-elastic-agent.md).
diff --git a/release-notes/elastic-cloud-serverless/index.md b/release-notes/elastic-cloud-serverless/index.md
index 0caff37b65..ddf9bf17c4 100644
--- a/release-notes/elastic-cloud-serverless/index.md
+++ b/release-notes/elastic-cloud-serverless/index.md
@@ -392,7 +392,7 @@ Review the changes, fixes, and more to {{serverless-full}}.
* Fixes `STATS` generated columns with an inline `WHERE` clause in {{esql}} [#260196]({{kib-pull}}260196)
* Fixes **Hosts** filter options to match the selected schema [#259825]({{kib-pull}}259825)
* Adds support for cross-cluster replication (CCR) to the Streams plugin, allowing replicated data streams to be viewed and partially managed in Kibana [#259175]({{kib-pull}}259175)
-* Converts notification policy and alert action endpoints from internal to public (experimental) [#260510]({{kib-pull}}260510)
+* Converts action policy and alert action endpoints from internal to public (experimental) [#260510]({{kib-pull}}260510)
* Adds visual and accessibility enhancements to the flyout UI [#259428]({{kib-pull}}259428)
* Applies post-enrichment filtering for Hosts exclusion filters [#260426]({{kib-pull}}260426)
* Fixes the index threshold rule's `filterKuery` producing incorrect queries for keyword wildcard fields [#260283]({{kib-pull}}260283)
diff --git a/solutions/observability/apm/create-apm-rules-alerts.md b/solutions/observability/apm/create-apm-rules-alerts.md
index 72f371a1b4..c1d7e3b322 100644
--- a/solutions/observability/apm/create-apm-rules-alerts.md
+++ b/solutions/observability/apm/create-apm-rules-alerts.md
@@ -28,7 +28,7 @@ The following APM rules are supported:
| **Latency threshold** | Alert when the latency or failed transaction rate is abnormal.Threshold rules can be as broad or as granular as you’d like, enabling you to define exactly when you want to be alerted—whether that’s at the environment level, service name level, transaction type level, and/or transaction name level. Read more in [Latency threshold rule →](/solutions/observability/incident-management/create-latency-threshold-rule.md) |
::::{tip}
-For a complete walkthrough of the **Create rule** flyout panel, including detailed information on each configurable property, see Kibana’s [Create and manage rules](/explore-analyze/alerting/alerts/create-manage-rules.md).
+For a complete walkthrough of the **Create rule** flyout panel, including detailed information on each configurable property, see Kibana’s [Create and manage rules](/explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md).
::::
@@ -67,8 +67,8 @@ From the Applications UI, select **Alerts and rules** → **Manage rules** to be
### More information [apm-alert-more-info]
-See [Alerting](/explore-analyze/alerting.md) for more information.
+See [Alerting](/explore-analyze/alerting-overview.md) for more information.
::::{note}
-If you are using an **on-premise** Elastic Stack deployment with security, communication between Elasticsearch and Kibana must have TLS configured. More information is in the alerting [prerequisites](/explore-analyze/alerting/alerts/alerting-setup.md#alerting-prerequisites).
+If you are using an **on-premise** Elastic Stack deployment with security, communication between Elasticsearch and Kibana must have TLS configured. More information is in the alerting [prerequisites](/explore-analyze/alerting/kibana-alerting-v1/alerting-setup-v1.md#alerting-prerequisites).
::::
\ No newline at end of file
diff --git a/solutions/observability/incident-management/create-a-degraded-docs-rule.md b/solutions/observability/incident-management/create-a-degraded-docs-rule.md
index 6550b88530..2f39fb7728 100644
--- a/solutions/observability/incident-management/create-a-degraded-docs-rule.md
+++ b/solutions/observability/incident-management/create-a-degraded-docs-rule.md
@@ -125,7 +125,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-a-failed-docs-rule.md b/solutions/observability/incident-management/create-a-failed-docs-rule.md
index c097e655a1..86f87a554b 100644
--- a/solutions/observability/incident-management/create-a-failed-docs-rule.md
+++ b/solutions/observability/incident-management/create-a-failed-docs-rule.md
@@ -133,7 +133,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-an-anomaly-detection-rule.md b/solutions/observability/incident-management/create-an-anomaly-detection-rule.md
index 57464ab832..946bb5c691 100644
--- a/solutions/observability/incident-management/create-an-anomaly-detection-rule.md
+++ b/solutions/observability/incident-management/create-an-anomaly-detection-rule.md
@@ -149,7 +149,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.anomalyExplorerUrl`
: URL to open in the Anomaly Explorer.
diff --git a/solutions/observability/incident-management/create-an-apm-anomaly-rule.md b/solutions/observability/incident-management/create-an-apm-anomaly-rule.md
index c02faf4edc..b1cb9cbc01 100644
--- a/solutions/observability/incident-management/create-an-apm-anomaly-rule.md
+++ b/solutions/observability/incident-management/create-an-apm-anomaly-rule.md
@@ -113,7 +113,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-an-elasticsearch-query-rule.md b/solutions/observability/incident-management/create-an-elasticsearch-query-rule.md
index d886ceeae5..096c0190de 100644
--- a/solutions/observability/incident-management/create-an-elasticsearch-query-rule.md
+++ b/solutions/observability/incident-management/create-an-elasticsearch-query-rule.md
@@ -187,7 +187,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.conditions`
: A string that describes the threshold condition. Example: `count greater than 4`.
diff --git a/solutions/observability/incident-management/create-an-error-count-threshold-rule.md b/solutions/observability/incident-management/create-an-error-count-threshold-rule.md
index 6071f2a2d3..9771b0055c 100644
--- a/solutions/observability/incident-management/create-an-error-count-threshold-rule.md
+++ b/solutions/observability/incident-management/create-an-error-count-threshold-rule.md
@@ -118,7 +118,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-an-inventory-rule.md b/solutions/observability/incident-management/create-an-inventory-rule.md
index dce50c3795..d5df2631ba 100644
--- a/solutions/observability/incident-management/create-an-inventory-rule.md
+++ b/solutions/observability/incident-management/create-an-inventory-rule.md
@@ -146,7 +146,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-an-slo-burn-rate-rule.md b/solutions/observability/incident-management/create-an-slo-burn-rate-rule.md
index 5ba47fcd07..ac72067175 100644
--- a/solutions/observability/incident-management/create-an-slo-burn-rate-rule.md
+++ b/solutions/observability/incident-management/create-an-slo-burn-rate-rule.md
@@ -127,7 +127,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-custom-threshold-rule.md b/solutions/observability/incident-management/create-custom-threshold-rule.md
index 0910165527..005d5a9d4b 100644
--- a/solutions/observability/incident-management/create-custom-threshold-rule.md
+++ b/solutions/observability/incident-management/create-custom-threshold-rule.md
@@ -265,7 +265,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-failed-transaction-rate-threshold-rule.md b/solutions/observability/incident-management/create-failed-transaction-rate-threshold-rule.md
index 12975ad284..9567355717 100644
--- a/solutions/observability/incident-management/create-failed-transaction-rate-threshold-rule.md
+++ b/solutions/observability/incident-management/create-failed-transaction-rate-threshold-rule.md
@@ -118,7 +118,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-latency-threshold-rule.md b/solutions/observability/incident-management/create-latency-threshold-rule.md
index befe2f368e..955f70af22 100644
--- a/solutions/observability/incident-management/create-latency-threshold-rule.md
+++ b/solutions/observability/incident-management/create-latency-threshold-rule.md
@@ -121,7 +121,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-log-threshold-rule.md b/solutions/observability/incident-management/create-log-threshold-rule.md
index 5d243d3980..ada1559423 100644
--- a/solutions/observability/incident-management/create-log-threshold-rule.md
+++ b/solutions/observability/incident-management/create-log-threshold-rule.md
@@ -165,7 +165,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You an also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You an also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-manage-rules.md b/solutions/observability/incident-management/create-manage-rules.md
index 8a29fed681..d2ee76ad4a 100644
--- a/solutions/observability/incident-management/create-manage-rules.md
+++ b/solutions/observability/incident-management/create-manage-rules.md
@@ -102,7 +102,7 @@ When you snooze a rule, the rule checks continue to run on a schedule but the al
When a rule is in a snoozed state, you can cancel or change the duration of this state.
-To temporarily suppress notifications for *all* rules, create a [maintenance window](/explore-analyze/alerting/alerts/maintenance-windows.md).
+To temporarily suppress notifications for *all* rules, create a [maintenance window](/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md).
## Import and export rules [observability-create-manage-rules-import-and-export-rules]
diff --git a/solutions/observability/incident-management/create-metric-threshold-rule.md b/solutions/observability/incident-management/create-metric-threshold-rule.md
index e94b812f6d..0c5a895329 100644
--- a/solutions/observability/incident-management/create-metric-threshold-rule.md
+++ b/solutions/observability/incident-management/create-metric-threshold-rule.md
@@ -165,7 +165,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You an also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You an also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.alertDetailsUrl`
: Link to the alert troubleshooting view for further context and details. This will be an empty string if the `server.publicBaseUrl` is not configured.
diff --git a/solutions/observability/incident-management/create-monitor-status-rule.md b/solutions/observability/incident-management/create-monitor-status-rule.md
index 537eae25e4..a08249dfe1 100644
--- a/solutions/observability/incident-management/create-monitor-status-rule.md
+++ b/solutions/observability/incident-management/create-monitor-status-rule.md
@@ -143,7 +143,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.checkedAt`
: Timestamp of the monitor run.
diff --git a/solutions/observability/incident-management/create-tls-certificate-rule.md b/solutions/observability/incident-management/create-tls-certificate-rule.md
index 14a31a0cfd..dcf725e3aa 100644
--- a/solutions/observability/incident-management/create-tls-certificate-rule.md
+++ b/solutions/observability/incident-management/create-tls-certificate-rule.md
@@ -135,7 +135,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.checkedAt`
: Timestamp of the monitor run.
@@ -287,7 +287,7 @@ Use the default notification message or customize it. You can add more context t
:screenshot:
:::
-The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/alerts/rule-action-variables.md).
+The following variables are specific to this rule type. You can also specify [variables common to all rules](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md).
`context.agingCommonNameAndDate`
: The common names and expiration date/time of the detected certs.
diff --git a/solutions/observability/incident-management/view-alerts.md b/solutions/observability/incident-management/view-alerts.md
index 0b732782ae..f8a1872dbd 100644
--- a/solutions/observability/incident-management/view-alerts.md
+++ b/solutions/observability/incident-management/view-alerts.md
@@ -26,7 +26,7 @@ You can track and manage alerts for your applications and SLOs from the **Alerts
% Stateful only for the following note
::::{note}
-You can centrally manage rules from the [{{kib}} Management UI](/explore-analyze/alerting/alerts/create-manage-rules.md) that provides a set of built-in [rule types](/explore-analyze/alerting/alerts/rule-types.md) and [connectors](/deploy-manage/manage-connectors.md) for you to use. Click **Manage Rules**.
+You can centrally manage rules from the [{{kib}} Management UI](/explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md) that provides a set of built-in [rule types](/explore-analyze/alerting/kibana-alerting-v1/rule-types-v1.md) and [connectors](/deploy-manage/manage-connectors.md) for you to use. Click **Manage Rules**.
::::
:::{image} /solutions/images/serverless-observability-alerts-view.png
@@ -86,14 +86,14 @@ The relevancy of alerts is determined by how closely they match the current aler
There are four common alert statuses:
`active`
-: The conditions for the rule are met. If the rule has [actions](../../../explore-analyze/alerting/alerts/create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings.
+: The conditions for the rule are met. If the rule has [actions](../../../explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings.
`flapping`
-: The alert switched repeatedly between active and recovered states. If actions are configured to run when its status changes, they are suppressed. Refer to [Configure alert flapping](/explore-analyze/alerting/alerts/create-manage-rules.md#defining-rules-flapping-details) to learn more about configuring alert flapping for rules.
+: The alert switched repeatedly between active and recovered states. If actions are configured to run when its status changes, they are suppressed. Refer to [Configure alert flapping](/explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md#defining-rules-flapping-details) to learn more about configuring alert flapping for rules.
`recovered`
-: The conditions for the rule are no longer met. If the rule has [recovery actions](../../../explore-analyze/alerting/alerts/create-manage-rules.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. Recovery actions only run if the rule's conditions aren't met during the current rule execution, but were in the previous one.
+: The conditions for the rule are no longer met. If the rule has [recovery actions](../../../explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md#defining-rules-actions-details), {{kib}} generates notifications based on the actions' notification settings. Recovery actions only run if the rule's conditions aren't met during the current rule execution, but were in the previous one.
An active alert changes to recovered if the conditions for the rule that generated it are no longer met.
@@ -186,7 +186,7 @@ Use the toolbar buttons in the upper-left of the alerts table to customize the c
* **x fields sorted**: Sort the table by one or more columns.
* **Fields**: Select the fields to display in the table.
-For example, click **Fields** and choose the `Maintenance Windows` field. If an alert was affected by a maintenance window, its identifier appears in the new column. For more information about their impact on alert notifications, refer to [{{maint-windows-cap}}](/explore-analyze/alerting/alerts/maintenance-windows.md).
+For example, click **Fields** and choose the `Maintenance Windows` field. If an alert was affected by a maintenance window, its identifier appears in the new column. For more information about their impact on alert notifications, refer to [{{maint-windows-cap}}](/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md).
You can also use the toolbar buttons in the upper-right to customize the display options or view the table in full-screen mode.
@@ -202,4 +202,4 @@ stack: ga 9.4+, preview 9.1-9.3
serverless: ga
```
-Manage the size of alert indices in your space by clearing out alerts that are older or infrequently accessed. You can do this by [running an alert cleanup task](../../../explore-analyze/alerting/alerts/view-alerts.md#clean-up-alerts), which deletes alerts according to the criteria that you define.
\ No newline at end of file
+Manage the size of alert indices in your space by clearing out alerts that are older or infrequently accessed. You can do this by [running an alert cleanup task](../../../explore-analyze/alerting/kibana-alerting-v1/view-alerts-v1.md#clean-up-alerts), which deletes alerts according to the criteria that you define.
\ No newline at end of file
diff --git a/solutions/observability/synthetics/cli.md b/solutions/observability/synthetics/cli.md
index 35e5f662e8..63e910edc8 100644
--- a/solutions/observability/synthetics/cli.md
+++ b/solutions/observability/synthetics/cli.md
@@ -181,7 +181,7 @@ If the journey contains external NPM packages other than the `@elastic/synthetic
This can also be set in the configuration file using [the `monitor.fields` option](/solutions/observability/synthetics/configure-projects.md#synthetics-configuration-monitor). The value defined via the CLI will take precedence.
`--maintenance-windows Array`
-: A list of maintenance window IDs used to associate every monitor with one or more [maintenance windows](/explore-analyze/alerting/alerts/maintenance-windows.md). This argument accepts a variable number of values as shown in the example.
+: A list of maintenance window IDs used to associate every monitor with one or more [maintenance windows](/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md). This argument accepts a variable number of values as shown in the example.
Example: `--maintenance-windows "maintenance-window-ID-1" "maintenance-window-ID-2`
diff --git a/solutions/observability/synthetics/configure-lightweight-monitors.md b/solutions/observability/synthetics/configure-lightweight-monitors.md
index 5e3ca25868..ca8b23386f 100644
--- a/solutions/observability/synthetics/configure-lightweight-monitors.md
+++ b/solutions/observability/synthetics/configure-lightweight-monitors.md
@@ -415,7 +415,7 @@ $$$monitor-maintenanceWindows$$$
**`maintenance_windows`**
: Type: [string](/solutions/observability/synthetics/configure-lightweight-monitors.md#synthetics-lightweight-data-string)
- A list of maintenance window IDs used to associate this monitor with one or more [maintenance windows](/explore-analyze/alerting/alerts/maintenance-windows.md).
+ A list of maintenance window IDs used to associate this monitor with one or more [maintenance windows](/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md).
**Examples**:
diff --git a/solutions/observability/synthetics/configure-projects.md b/solutions/observability/synthetics/configure-projects.md
index dbf47653ef..81c3733ed4 100644
--- a/solutions/observability/synthetics/configure-projects.md
+++ b/solutions/observability/synthetics/configure-projects.md
@@ -302,7 +302,7 @@ For information on configuring monitors individually, refer to:
* [Configure lightweight monitors](/solutions/observability/synthetics/configure-lightweight-monitors.md) for lightweight monitors
`maintenanceWindows` (`Array`)
-: A list of maintenance window IDs used to associate this monitor with one or more [maintenance windows](/explore-analyze/alerting/alerts/maintenance-windows.md).
+: A list of maintenance window IDs used to associate this monitor with one or more [maintenance windows](/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md).
## `proxy` [synthetics-configuration-proxy]
diff --git a/solutions/security/detect-and-alert/common-rule-settings.md b/solutions/security/detect-and-alert/common-rule-settings.md
index 8022f9d641..c4d0cf2a88 100644
--- a/solutions/security/detect-and-alert/common-rule-settings.md
+++ b/solutions/security/detect-and-alert/common-rule-settings.md
@@ -217,7 +217,7 @@ Host isolation involves quarantining a host from the network to prevent further
You can use [mustache syntax](http://mustache.github.io/) to add variables to notification messages. The action frequency you select determines the available variables.
::::{note}
-Refer to [Action frequency: Summary of alerts](/explore-analyze/alerting/alerts/rule-action-variables.md#alert-summary-action-variables) to learn about additional variables that can be passed if the rule's action frequency is **Summary of alerts**.
+Refer to [Action frequency: Summary of alerts](/explore-analyze/alerting/kibana-alerting-v1/rule-action-variables-v1.md#alert-summary-action-variables) to learn about additional variables that can be passed if the rule's action frequency is **Summary of alerts**.
::::
### Variables for all rules [all-rule-variables]
diff --git a/solutions/security/detect-and-alert/cross-cluster-search-detection-rules.md b/solutions/security/detect-and-alert/cross-cluster-search-detection-rules.md
index c6270b70c2..1158ae5c44 100644
--- a/solutions/security/detect-and-alert/cross-cluster-search-detection-rules.md
+++ b/solutions/security/detect-and-alert/cross-cluster-search-detection-rules.md
@@ -78,7 +78,7 @@ This section explains the general process for setting up cross-cluster search in
## Update a rule’s API key [update-api-key]
-Each detection rule has its own [API key](../../../explore-analyze/alerting/alerts/alerting-setup.md#alerting-authorization), which determines the data and actions the rule is allowed to access. When a user creates a new rule or changes an existing rule, their current privileges are saved to the rule’s API key. If that user’s privileges change in the future, the rule **does not** automatically update with the user’s latest privileges — you must update the rule’s API key if you want to update its privileges.
+Each detection rule has its own [API key](../../../explore-analyze/alerting/kibana-alerting-v1/alerting-setup-v1.md#alerting-authorization), which determines the data and actions the rule is allowed to access. When a user creates a new rule or changes an existing rule, their current privileges are saved to the rule’s API key. If that user’s privileges change in the future, the rule **does not** automatically update with the user’s latest privileges — you must update the rule’s API key if you want to update its privileges.
::::{important}
A rule’s API key is different from the API key you might have created for [authentication between local and remote clusters](#set-up-ccs-rules).
diff --git a/solutions/security/detect-and-alert/manage-detection-alerts.md b/solutions/security/detect-and-alert/manage-detection-alerts.md
index ed7cc9d3eb..7679b29a16 100644
--- a/solutions/security/detect-and-alert/manage-detection-alerts.md
+++ b/solutions/security/detect-and-alert/manage-detection-alerts.md
@@ -300,4 +300,4 @@ stack: ga 9.4+, preview 9.1-9.3
serverless: ga
```
-Manage the size of alert indices in your space by clearing out alerts that are older or infrequently accessed. You can do this by [running an alert cleanup task](../../../explore-analyze/alerting/alerts/view-alerts.md#clean-up-alerts), which deletes alerts according to the criteria that you define.
\ No newline at end of file
+Manage the size of alert indices in your space by clearing out alerts that are older or infrequently accessed. You can do this by [running an alert cleanup task](../../../explore-analyze/alerting/kibana-alerting-v1/view-alerts-v1.md#clean-up-alerts), which deletes alerts according to the criteria that you define.
\ No newline at end of file
diff --git a/solutions/security/detect-and-alert/manage-detection-rules.md b/solutions/security/detect-and-alert/manage-detection-rules.md
index b9c4677634..c90e297cda 100644
--- a/solutions/security/detect-and-alert/manage-detection-rules.md
+++ b/solutions/security/detect-and-alert/manage-detection-rules.md
@@ -83,7 +83,7 @@ Use bulk editing to update settings on multiple rules simultaneously. Rules that
* **Index patterns**: Add or delete the index patterns used by all selected rules.
* **Tags**: Add or delete tags on all selected rules.
* **Custom highlighted fields**: Add custom highlighted fields on all selected rules. You can choose any fields that are available in the [default {{elastic-sec}} indices](/solutions/security/get-started/configure-advanced-settings.md#update-sec-indices), or enter field names from other indices. To overwrite a rule's current set of custom highlighted fields, select the **Overwrite all selected rules' custom highlighted fields** option, then click **Save**.
- * **Add rule actions**: Add [rule actions](/solutions/security/detect-and-alert/common-rule-settings.md#rule-notifications) on all selected rules. If you add multiple rule actions, you can specify an action frequency for each of them. To overwrite the frequency of existing rule actions, select the option to **Overwrite all selected rules actions**. Keep in mind that rule actions won't run during a [maintenance window](/explore-analyze/alerting/alerts/maintenance-windows.md) or while the rule is [snoozed](#snooze-rule-actions); they'll resume after the maintenance window or snooze period ends.
+ * **Add rule actions**: Add [rule actions](/solutions/security/detect-and-alert/common-rule-settings.md#rule-notifications) on all selected rules. If you add multiple rule actions, you can specify an action frequency for each of them. To overwrite the frequency of existing rule actions, select the option to **Overwrite all selected rules actions**. Keep in mind that rule actions won't run during a [maintenance window](/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md) or while the rule is [snoozed](#snooze-rule-actions); they'll resume after the maintenance window or snooze period ends.
* **Update rule schedules**: Update the [schedules](/solutions/security/detect-and-alert/common-rule-settings.md#rule-schedule) and look-back times on all selected rules.
* **Apply Timeline template**: Apply a specified [Timeline template](/solutions/security/investigate/timeline-templates.md) to the selected rules. You can also choose **None** to remove Timeline templates from the selected rules.
diff --git a/solutions/security/detect-and-alert/reduce-noise-and-false-positives.md b/solutions/security/detect-and-alert/reduce-noise-and-false-positives.md
index 4c7ca38344..93d9cbd434 100644
--- a/solutions/security/detect-and-alert/reduce-noise-and-false-positives.md
+++ b/solutions/security/detect-and-alert/reduce-noise-and-false-positives.md
@@ -66,7 +66,7 @@ Acts on: **notifications, after alerts are created and stored**
*"Don't trigger any actions right now. I'll review later."*
-Temporarily pause all of a rule's actions—including notifications (emails, Slack messages, webhooks), ticket creation, and other automated responses—without affecting rule execution or alert creation. Alerts generated during a snooze period are stored normally and visible in the Alerts UI. Snoozing expires automatically or can be canceled manually. For space-wide pausing, use a [maintenance window](/explore-analyze/alerting/alerts/maintenance-windows.md).
+Temporarily pause all of a rule's actions—including notifications (emails, Slack messages, webhooks), ticket creation, and other automated responses—without affecting rule execution or alert creation. Alerts generated during a snooze period are stored normally and visible in the Alerts UI. Snoozing expires automatically or can be canceled manually. For space-wide pausing, use a [maintenance window](/explore-analyze/alerting/kibana-alerting-v1/maintenance-windows-v1.md).
Refer to [Snooze rule actions](/solutions/security/detect-and-alert/manage-detection-rules.md#snooze-rule-actions) for more guidance.
diff --git a/solutions/security/detect-and-alert/using-logsdb-index-mode-with-elastic-security.md b/solutions/security/detect-and-alert/using-logsdb-index-mode-with-elastic-security.md
index 373702c0da..ced819ea49 100644
--- a/solutions/security/detect-and-alert/using-logsdb-index-mode-with-elastic-security.md
+++ b/solutions/security/detect-and-alert/using-logsdb-index-mode-with-elastic-security.md
@@ -63,7 +63,7 @@ Alerts that are generated by threshold, {{ml}}, and event correlation sequence r
While we do not recommend using `_source` for actions, in cases where the action relies on the `_source`, the same limitations and changes apply.
-If you send alert notifications by enabling [actions](/explore-analyze/alerting/alerts.md#rules-actions) to the external systems that have workflows or automations based on fields formatted from the original source, they may be affected. In particular, this can happen when the fields used are arrays of objects.
+If you send alert notifications by enabling [actions](/explore-analyze/alerting/kibana-alerting-v1.md#rules-actions) to the external systems that have workflows or automations based on fields formatted from the original source, they may be affected. In particular, this can happen when the fields used are arrays of objects.
We recommend checking and adjusting the rule actions using `_source` before switching to logsdb index mode.
diff --git a/troubleshoot/elasticsearch/mapping-explosion.md b/troubleshoot/elasticsearch/mapping-explosion.md
index 411f559b86..6e3194bcbf 100644
--- a/troubleshoot/elasticsearch/mapping-explosion.md
+++ b/troubleshoot/elasticsearch/mapping-explosion.md
@@ -32,7 +32,7 @@ Mapping explosion may surface as the following performance symptoms:
* [CAT pending tasks]({{es-apis}}operation/operation-cat-pending-tasks) reporting a task queue backlog with a lot of `put-mapping [MY_INDEX_NAME/MY_INDEX_UUID]` messages.
* Discover’s **Fields for wildcard** page-loading API command or [Dev Tools](../../explore-analyze/query-filter/tools/console.md) page-refreshing Autocomplete API commands are taking a long time (more than 10 seconds) or timing out in the browser’s Developer Tools Network tab. For more information, refer to our [walkthrough on troubleshooting Discover](https://www.elastic.co/blog/troubleshooting-guide-common-issues-kibana-discover-load).
* Discover’s **Available fields** taking a long time to compile Javascript in the browser’s Developer Tools Performance tab. This may potentially escalate to temporary browser page unresponsiveness.
-* Kibana’s [alerting](../../explore-analyze/alerting/alerts.md) or [security rules](../../solutions/security/detect-and-alert.md) may error `The content length (X) is bigger than the maximum allowed string (Y)` where `X` is attempted payload and `Y` is {{kib}}'s [`server-maxPayload`](kibana://reference/configuration-reference/general-settings.md#server-maxpayload).
+* Kibana’s [alerting](../../explore-analyze/alerting/kibana-alerting-v1.md) or [security rules](../../solutions/security/detect-and-alert.md) may error `The content length (X) is bigger than the maximum allowed string (Y)` where `X` is attempted payload and `Y` is {{kib}}'s [`server-maxPayload`](kibana://reference/configuration-reference/general-settings.md#server-maxpayload).
* Long {{es}} start-up durations.
* Kibana Javascript erring within browser while loading a Dashboard or Discover with message `Maximum call stack size exceeded`.
diff --git a/troubleshoot/elasticsearch/task-queue-backlog.md b/troubleshoot/elasticsearch/task-queue-backlog.md
index a897b63c9c..ffac2cebf2 100644
--- a/troubleshoot/elasticsearch/task-queue-backlog.md
+++ b/troubleshoot/elasticsearch/task-queue-backlog.md
@@ -141,7 +141,7 @@ If an individual task is causing a [thread pool `queue`](#diagnose-task-queue-th
This problem can surface due to a number of possible causes:
-* Creating new tasks or modifying scheduled tasks which either run frequently or are broad in their effect, such as [{{ilm}}](/manage-data/lifecycle/index-lifecycle-management.md) policies or [rules](/explore-analyze/alerting.md)
+* Creating new tasks or modifying scheduled tasks which either run frequently or are broad in their effect, such as [{{ilm}}](/manage-data/lifecycle/index-lifecycle-management.md) policies or [rules](/explore-analyze/alerting-overview.md)
* Performing traffic load testing
* Doing extended look-backs, especially across [data tiers](/manage-data/lifecycle/data-tiers.md)
* [Searching]({{es-apis}}group/endpoint-search) or performing [bulk updates]({{es-apis}}operation/operation-bulk) to a high number of indices in a single request
diff --git a/troubleshoot/kibana/alerts.md b/troubleshoot/kibana/alerts.md
index 79ef2c91d8..8a8a54bd5f 100644
--- a/troubleshoot/kibana/alerts.md
+++ b/troubleshoot/kibana/alerts.md
@@ -29,13 +29,13 @@ Some of the resources, such as saved objects and API keys, may no longer be avai
The following debugging tools are available:
-* {{kib}} versions 7.10 and above have a [Test connector](../../explore-analyze/alerting/alerts/testing-connectors.md) UI.
+* {{kib}} versions 7.10 and above have a [Test connector](../../explore-analyze/alerting/kibana-alerting-v1/testing-connectors-v1.md) UI.
* {{kib}} versions 7.11 and above include improved Webhook error messages, better overall debug logging for actions and connectors, and Task Manager [diagnostics endpoints](task-manager.md#task-manager-diagnosing-root-cause).
## Using rules and connectors list for the current state and finding issues [alerting-managment-detail]
-**{{rules-ui}}** in **{{stack-manage-app}}** lists the rules available in the space you’re currently in. When you click a rule name, you are navigated to the [details page](../../explore-analyze/alerting/alerts/create-manage-rules.md#rule-details) for the rule, where you can see currently active alerts. The start date on this page indicates when a rule is triggered, and for what alerts. In addition, the duration of the condition indicates how long the instance is active.
+**{{rules-ui}}** in **{{stack-manage-app}}** lists the rules available in the space you’re currently in. When you click a rule name, you are navigated to the [details page](../../explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md#rule-details) for the rule, where you can see currently active alerts. The start date on this page indicates when a rule is triggered, and for what alerts. In addition, the duration of the condition indicates how long the instance is active.
:::{image} /troubleshoot/images/kibana-rule-details-alerts-inactive.png
:alt: Alerting management details
@@ -188,9 +188,9 @@ Investigating the underlying task can help you gauge whether the problem you’r
In addition to the above methods, refer to the following approaches and common issues:
-* [Alerting common issues](../../explore-analyze/alerting/alerts/alerting-common-issues.md)
-* [Querying event log index](../../explore-analyze/alerting/alerts/event-log-index.md)
-* [Testing connectors using {{connectors-ui}} UI and the `kbn-action` tool](../../explore-analyze/alerting/alerts/testing-connectors.md)
+* [Alerting common issues](../../explore-analyze/alerting/kibana-alerting-v1/alerting-common-issues-v1.md)
+* [Querying event log index](../../explore-analyze/alerting/kibana-alerting-v1/event-log-index-v1.md)
+* [Testing connectors using {{connectors-ui}} UI and the `kbn-action` tool](../../explore-analyze/alerting/kibana-alerting-v1/testing-connectors-v1.md)
### Temporarily throttle all tasks [alerting-kibana-throttle]
@@ -203,7 +203,7 @@ xpack.task_manager.poll_interval: 1h
```
::::{warning}
-This approach should be used only temporarily as a last resort to restore function to {{kib}} when it is unresponsive and attempts to identify and [snooze or disable](../../explore-analyze/alerting/alerts/create-manage-rules.md#controlling-rules) slow-running rules have not fixed the situation. It severely throttles all background tasks, not just those relating to {{alert-features}}. The task manager will run only one task at a time and will look for more work each hour.
+This approach should be used only temporarily as a last resort to restore function to {{kib}} when it is unresponsive and attempts to identify and [snooze or disable](../../explore-analyze/alerting/kibana-alerting-v1/create-manage-rules-v1.md#controlling-rules) slow-running rules have not fixed the situation. It severely throttles all background tasks, not just those relating to {{alert-features}}. The task manager will run only one task at a time and will look for more work each hour.
::::
diff --git a/troubleshoot/kibana/task-manager.md b/troubleshoot/kibana/task-manager.md
index 1c5cc30b9f..cd3876babc 100644
--- a/troubleshoot/kibana/task-manager.md
+++ b/troubleshoot/kibana/task-manager.md
@@ -54,7 +54,7 @@ For most performance issues, the subsections indicate explicit health issues thr
::::{important}
Some tasks (such as [connector](/deploy-manage/manage-connectors.md) tasks) can incorrectly report their status as successful even when the task failed. The runtime and workload block return data about successes and failures and don't take this into consideration.
-To get a better sense of action failures, refer to the [Event log index](/explore-analyze/alerting/alerts/event-log-index.md) for more accurate context about failures and successes.
+To get a better sense of action failures, refer to the [Event log index](/explore-analyze/alerting/kibana-alerting-v1/event-log-index-v1.md) for more accurate context about failures and successes.
::::