[Alerting V2][Serverless & 9.5][M2] Edit and improve get-started docs; address issues #1419 and #1420 (#7213)

## Summary

Comprehensive edits to the experimental alerting system get-started
documentation. Addresses two internal tracking issues
([#1419](elastic/docs-content-internal#1419) —
implicit Elasticsearch privilege grant for the Alerts privilege, and
[#1420](elastic/docs-content-internal#1420) —
setup prerequisites), and applies structural, editorial, and clarity
improvements across all four pages in the section.

---

## Content changes

### `get-started.md`

Updated the landing page intro and all three child page descriptions to
accurately reflect the current content of each page. Updated the
frontmatter description.

---

### `get-started/setup.md`

- Added a **Requirements** section covering license requirements
(Enterprise required for Workflows-based notifications on Stack; no
restriction on Serverless), data prerequisites, connectors, and space
selection.
- Moved the `configure-access.md` cross-reference earlier in the page
(after the "Confirm the UI is accessible" step) rather than only in Next
steps.
- Simplified the "Turn on the system" tab-set by removing the
`**Requirement:**` / `**Steps:**` heading pattern and inlining the role
requirement.
- Updated frontmatter description to reflect the page's actual scope
(requirements + on/off mechanics).

---

### `get-started/configure-access.md`

Addresses
[#1419](elastic/docs-content-internal#1419):

- **Quick Reference table**: Split the single "Query rule and episode
data in Discover" row into two rows — one for
`.rule-events`/`.alert-actions` (access bundled with the Alerts
privilege) and one for `.kibana-event-log-*` (still requires a custom
role).
- **Triage alerts section**: Added a note that granting **Alerts: All**
or **Alerts: Read** automatically includes Elasticsearch `read` access
to `.rule-events` and `.alert-actions`, with no separate index privilege
needed.
- **ES index access section**: Rewrote to clarify the access method per
data source. `.rule-events` and `.alert-actions` access is bundled with
the Alerts privilege; `.kibana-event-log-*` still requires a custom
role. Custom-role fallback preserved for the two auto-granted streams.
- Added **Next steps** section with a link to the tutorial and
commented-out links for notifications and rules content pending PRs
#6523 and #6525.

---

### `get-started/create-your-first-rule.md`

**Structure:**
- Separated environment setup (index creation, sample data) from the
rule creation workflow into a dedicated **Prepare your environment**
section with its own stepper.
- Split the single "Create the rule" stepper step into five focused
steps: Open the rule editor, Write and test the detection query,
Configure the alert condition, Configure the recovery condition, and
Name and save the rule.
- Moved "Confirm the rule is evaluating" and "Observe the episode
lifecycle" out of the Tutorial stepper and into standalone `##`
sections, since they're observational steps after rule creation, not
part of the creation workflow itself.

**Content:**
- Rewrote the page intro to be high-level and inviting, with a numbered
task list that previews each section and explains its purpose.
- Added a intro paragraph to "Prepare your environment", "Create the
rule", and "Observe the episode lifecycle" to orient users before the
steps begin.
- Added brief explanations for the detection query (what `PERCENTILE`,
`CASE`, and `WHERE` do) and the lifecycle query (what `STATS ... BY`
produces), for readers new to ES|QL.
- Simplified time-phase descriptions (removed redundant minute-count
approximations; standardized on clock times).
- Shortened and simplified the timestamp update note.
- Improved sandbox recovery preview explanation — framed as a preview of
recovery behavior rather than a "verification step."
- Fixed step numbering bug in "Observe the episode lifecycle" (step `3`
was mislabeled).

**Requirements section** (addresses
[#1420](elastic/docs-content-internal#1420)):
- Replaced the manual `read` index privilege on `.rule-events` with
**Alerts: Read**, noting that this automatically grants Elasticsearch
access with no separate index privilege needed.
- Added **Discover: Read** as an explicit requirement.
- Added `create_index` and `write` index privileges on
`checkout-service-logs`.
- Reformatted requirements as a table (Task / Required privilege) for
scannability.

**Editorial:**
- Removed all em dashes throughout.
- Replaced `"via"` with `"using"`.
- Replaced bold-header prose blocks with properly structured lists and
tables.

---

## Out of scope

- Rules reference docs (PR #6523)
- Action policies and notifications docs (PR #6525)
- Alerts/Discover query docs (PR #6527)
- ECH-specific setup behavior for the `xpack.alerting_v2.enabled` flag
(pending engineering confirmation; placeholder comment left in
`setup.md`)

---

## Generative AI disclosure

- Yes — Cursor + Claude

Author: nastasha-solomon

explore-analyze/alerting/kibana-alerting-experimental/get-started.md

@@ -6,13 +6,13 @@ applies_to:
 products:
   - id: kibana
   - id: cloud-serverless
-description: "Enable the experimental alerting system in Kibana, configure role access, and create your first rule."
+description: "Get started with the experimental alerting system in Kibana: review requirements, enable the system, configure role access, and follow a tutorial to create a rule and observe the alert lifecycle."
 ---
 
 # Get started with the {{alerting-v2-system}} [alerting-v2-get-started]
 
 Use these guides to get the {{alerting-v2-system}} running in your space, set up role access for your team, and create your first rule.
 
-- [Turn on the {{alerting-v2-system-cap}}](get-started/setup.md): Enable the `alerting:v2:enabled` advanced setting and confirm the system is accessible in your space.
-- [Configure access](get-started/configure-access.md): Set up a role with the {{kib}} feature privileges and {{es}} index privileges needed to create rules and query alert data.
-- [Create your first rule](get-started/create-your-first-rule.md): A hands-on tutorial that walks you through loading sample data, creating a rule, and watching the alert lifecycle play out from breach to recovery.
+- [Set up the {{alerting-v2-system-cap}}](get-started/setup.md): Review requirements, enable the `alerting:v2:enabled` advanced setting, and confirm the system is accessible in your space.
+- [Configure access](get-started/configure-access.md): Set up a role with the {{kib}} feature privileges needed to create rules, triage alerts, and query alert data.
+- [Create your first rule](get-started/create-your-first-rule.md): A hands-on tutorial that walks you through loading sample data, creating a rule, and observing the alert lifecycle from breach through automatic recovery.

explore-analyze/alerting/kibana-alerting-experimental/get-started/configure-access.md

@@ -29,7 +29,8 @@ The following table shows the minimum privileges required for each activity. Hig
 | Monitor rule execution | **Execution history: Read** (under **Alerting**) |
 | Triage alert episodes | **Alerts: All** (under **Alerting**) |
 | Configure notifications | **Action Policies: All** (under **Alerting**) + **Workflows: Read** (under **Analytics > Workflows**) |
-| Query rule and episode data in Discover | **Discover: Read** (under **Analytics > Discover**) + `read` index privilege on the relevant data stream |
+| Query `.rule-events` and `.alert-actions` in Discover | **Discover: Read** (under **Analytics > Discover**) + **Alerts: Read** (Elasticsearch `read` access is bundled automatically) |
+| Query `.kibana-event-log-*` in Discover | **Discover: Read** (under **Analytics > Discover**) + custom role with `read` index privilege on `.kibana-event-log-*` |
 
 ## Author and monitor rules [alerting-authoring-monitoring-privileges]
 
@@ -66,6 +67,10 @@ The **Alerts** privilege controls who can take triage actions on alert episodes.
 | **All** | Acknowledge, snooze, assign, tag, activate, and deactivate alert episodes |
 | **Read** | View alert episodes |
 
+:::{note}
+Granting **Alerts: All** or **Alerts: Read** also gives the role direct Elasticsearch `read` access to `.rule-events` and `.alert-actions`, scoped to that role's spaces. This is bundled into the privilege — no separate custom role or index privilege is needed to query these data streams in Discover.
+:::
+
 ## Configure notifications [alerting-notifications-privileges]
 
 These privileges control who can set up the action policies and workflows that route alert episode notifications.
@@ -109,16 +114,25 @@ Both levels grant the same query access. There is no write surface for any of th
 
 ### {{es}} index access
 
-Each data source requires a separate `read` index privilege:
+For `.rule-events` and `.alert-actions`, Elasticsearch `read` access is bundled into the **Alerts** Kibana privilege — nothing extra to configure. For `.kibana-event-log-*`, a custom role is still required.
 
-| Data source | What it stores | Required privilege |
+| Data source | What it stores | How to grant access |
 |---|---|---|
-| `.rule-events` | A record for every rule evaluation — one document per result row per run | `read` |
-| `.alert-actions` | Episode action records: acknowledge, snooze, resolve, assign, and other triage operations | `read` |
-| `.kibana-event-log-*` | Action policy dispatch outcomes written by the dispatcher: `dispatched`, `throttled`, and `unmatched` | `read` |
+| `.rule-events` | A record for every rule evaluation; one document per result row per run | Automatic with **Alerts: All** or **Alerts: Read**. If access is missing, grant `read` using a custom role as a fallback. |
+| `.alert-actions` | Episode action records: acknowledge, snooze, resolve, assign, and other triage operations | Automatic with **Alerts: All** or **Alerts: Read**. If access is missing, grant `read` using a custom role as a fallback. |
+| `.kibana-event-log-*` | Action policy dispatch outcomes written by the dispatcher: `dispatched`, `throttled`, and `unmatched` | Custom role with `read` index privilege. Not covered by the automatic grant. |
+
+## Next steps [alerting-access-next-steps]
 
-Because `.rule-events` and `.alert-actions` are hidden system data streams, request access through a custom role with the appropriate index privileges.
+With access configured, you're ready to start using the {{alerting-v2-system}}:
 
-<!-- TODO: Uncomment when PR #6527 (alerts) is merged, and add as a link in the note under the Rules section:
-For step-by-step instructions, refer to [Create a rule from Discover](../alerts/query-alerts-and-signals-in-discover.md).
+- **[Create your first rule](create-your-first-rule.md):** Follow the tutorial to create an ES|QL rule, load sample data, and watch the alert episode lifecycle from breach through automatic recovery.
+
+<!-- TODO: Uncomment when PR #6523 (rules) is merged:
+- **[Create a rule](../rules/create-a-rule.md):** Write the {{esql}} query that defines what to detect, choose Signal or Alert mode, and configure grouping and thresholds.
+-->
+<!-- TODO: Uncomment when PR #6525 (workflows/notifications) is merged:
+- **[Set up workflows](../workflows-alerting.md):** Configure the automation objects that deliver notifications — email, Slack, webhook, and so on.
+- **[Create action policies](../action-policies/create-configure-action-policy.md):** Define who gets notified, how often, and under what conditions.
 -->
+