[Alerting V2][Serverless & 9.5][M2] Add experimental alerting features overview pages

docset.yml

@@ -124,8 +124,8 @@ subs:
   ls-pipelines-app:   "Logstash Pipelines"
   maint-windows-app:   "Maintenance Windows"
   maint-windows-cap:   "Maintenance windows"
-  alerting-v2:   "experimental alerting features"
-  alerting-v2-cap:   "Experimental alerting features"
+  alerting-v2-system:   "experimental alerting system"
+  alerting-v2-system-cap:   "Experimental alerting system"
   custom-roles-app:   "Custom Roles"
   data-source:   "data view"
   data-sources:   "data views"

explore-analyze/alerting.md

@@ -8,28 +8,55 @@ applies_to:
 products:
   - id: kibana
   - id: cloud-serverless
+  - id: elasticsearch
+  - id: cloud-hosted
+navigation_title: Alerting
+description: Watch your data and respond to conditions automatically with Elastic alerting. Compare Kibana alerting, the experimental ES|QL-based alerting system, and Watcher to find the right fit.
 ---
 
-# Alerting
+# Alerting [alerting-overview]
 
-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.
+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.
 
-## Alerts
+Elastic offers three alerting systems, summarized below. Each has a **Get started** link to the full guide for that option. If you're not sure which to use, refer to [Choose an alerting system](alerting/choose-an-alerting-system.md).
 
-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. 
+## {{kib}} alerting
 
-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.
+```{applies_to}
+stack: ga
+serverless: ga
+```
+
+{{kib}} alerting 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 {{kib}} alerting →](alerting/alerts.md)
+
+## {{alerting-v2-system-cap}}
+
+```{applies_to}
+stack: experimental 9.5+
+serverless: experimental
+```
+
+The {{alerting-v2-system}} is built on {{esql}}. You write the query that defines what to watch for, choose how alert episodes are tracked per series, and control notifications through action policies that handle routing, frequency, and notification batching. The {{alerting-v2-system}} also adds alert episode lifecycle tracking, per-series snooze, and rules on alert episodes for correlation and escalation. It is a strong fit when you want full control over what data travels with each alert episode and how your team is notified.
+
+:::{note}
+The {{alerting-v2-system}} runs next to {{kib}} alerting on {{serverless-full}} and {{stack}} 9.5 and later. You do not have to move everything at once. Teams can copy or rebuild rules when they are ready. {{kib}} alerting will remain available.
+:::
+
+[Get started with the {{alerting-v2-system}} →](alerting/kibana-alerting-experimental.md)
 
 ## Watcher
+
 ```{applies_to}
+stack: ga
 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.
+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 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}}.
+For most teams, {{kib}} alerting or the {{alerting-v2-system}} is easier to adopt than Watcher: both work within {{kib}}'s rules UI and don't require writing {{es}} watch definitions.
 :::
 
+[Get started with Watcher →](alerting/watcher.md)

explore-analyze/alerting/choose-an-alerting-system.md

@@ -0,0 +1,38 @@
+---
+applies_to:
+  stack: ga
+  serverless: ga
+products:
+  - id: kibana
+  - id: cloud-serverless
+  - id: elasticsearch
+  - id: cloud-hosted
+description: Compare Kibana alerting, the experimental ES|QL-based alerting system, and Watcher by use case and deployment type to select the right tool for your monitoring needs.
+---
+
+# 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 |
+|---|---|
+| Monitor metrics, logs, or uptime with ready-made rules and no query language | [{{kib}} alerting](alerts.md) |
+| Use rules built for Security, Observability, APM, or Maps | [{{kib}} alerting](alerts.md) |
+| Write {{esql}} to define exactly what to detect and what data each alert episode carries | [{{alerting-v2-system-cap}}](kibana-alerting-experimental.md) {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
+| Query alert history in Discover or build dashboards from alert data | [{{alerting-v2-system-cap}}](kibana-alerting-experimental.md) {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
+| Manage notification routing, grouping, and throttling in one place, reusable across rules | [{{alerting-v2-system-cap}}](kibana-alerting-experimental.md) {applies_to}`serverless: experimental` {applies_to}`stack: experimental 9.5+` |
+| Build highly custom logic with scripting and chained inputs | [Watcher](watcher.md) {applies_to}`stack: ga` {applies_to}`serverless: unavailable` |
+
+## Compare at a glance
+
+| | {{kib}} alerting | {{alerting-v2-system-cap}} | 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** | In-place updates, 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-episode acknowledge or deactivate, per-series snooze, maintenance windows, match condition routing in action policies | Action conditions and throttling |
+| **Available on {{serverless-full}}** | Yes | Yes, {applies_to}`serverless: experimental` | No |
+| **Available on {{stack}}** | Yes | Yes, {applies_to}`stack: experimental 9.5+` | Yes |