[Alerting v2][Serverless & 9.5]: Docs for initial public release (M2)

deploy-manage/deploy/cloud-on-k8s/k8s-service-mesh-istio.md

@@ -12,10 +12,10 @@
 
 The instructions in this section describe how to connect the operator and managed resources to the Istio service mesh and assume that Istio is already installed and configured on your Kubernetes cluster. To know more about Istio and how to install it, check the [product documentation](https://istio.io).
 
 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.
 ::::
 
 

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
 

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.
 
 

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
 

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.

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.

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}}

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. 

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).
 
 ::::
 

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.
 

deploy-manage/production-guidance/kibana-task-manager-scaling-considerations.md

@@ -12,9 +12,9 @@
   - id: kibana
 ---
 
 # {{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.

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.