Skip to content

[Alerting V2][Serverless & 9.5][M2] Adds docs for action policies, workflows, and notifications#6525

Open
nastasha-solomon wants to merge 36 commits into
mainfrom
alerting/experimental-workflows
Open

[Alerting V2][Serverless & 9.5][M2] Adds docs for action policies, workflows, and notifications#6525
nastasha-solomon wants to merge 36 commits into
mainfrom
alerting/experimental-workflows

Conversation

@nastasha-solomon

@nastasha-solomon nastasha-solomon commented May 15, 2026

Copy link
Copy Markdown
Member

Summary

Adds documentation for notifications, action policies, and workflow connections for the experimental alerting system, contributing to docs-content-internal#919. Following the tech preview principle of accuracy over comprehensiveness, pages focus on stable concepts — what the system does, when to choose each feature, and how the components connect — rather than UI-level procedures that are subject to change before GA.

Navigation structure

Notifications and actions          ← section landing page
├── Connect workflows
├── About action policies          
├── Action policy scenarios        
│   ├── Route alert episodes by severity
│   ├── Manage severity escalation notifications
│   └── Re-notify for persistently active episodes
├── Create an action policy
├── Action policy reference
├── Manage action policies
├── Review execution history       
└── Reduce notification noise

Workflows (updated pages)
└── Triggers
    ├── triggers.md                ← rule lifecycle trigger family added
    └── Event-driven triggers      ← rule lifecycle triggers section added

Review requests

This PR needs a technical and editorial review. Instructions for each are below.

🔧 Technical reviewer

Please focus your review on accuracy of facts, names, and structure. Verify that field names, values, and descriptions in reference material match the current implementation. When reviewing conceptual content, check that definitions are technically accurate and reflect the current engineering design.

✏️ Editorial reviewer

This PR adds the full notifications and action policies documentation set for the experimental alerting system. As you're reviewing, please focus on writing quality, clarity, and how the content serves a reader who's seeing this system for the first time. Pay particular attention to the action policy reference, the about-action-policies conceptual page, and the three scenario sub-pages.

Previews

Section landing page

Page name Description File ✏️ Ready for editorial review 🔧 Ready for technical review
Notifications and actions Section landing page; workflow + action policy model, get-started flow, related pages index explore-analyze/alerting/kibana-alerting-experimental/notifications-actions.md
Connect workflows How the alerting system connects to workflows through action policies and lifecycle triggers; choosing between pathways explore-analyze/alerting/kibana-alerting-experimental/workflows-alerting.md

Action policies: conceptual and how-to

Page name Description File ✏️ Ready for editorial review 🔧 Ready for technical review
About action policies Conceptual guide: three gates, policy types, dispatcher evaluation sequence explore-analyze/alerting/kibana-alerting-experimental/action-policies/about-action-policies.md
Create an action policy Creation and configuration guide: policy type, tags, match conditions, notify per, frequency, destinations explore-analyze/alerting/kibana-alerting-experimental/action-policies/create-configure-action-policy.md
Action policy reference Full match conditions field reference, notify per options, frequency options, dispatch outcomes explore-analyze/alerting/kibana-alerting-experimental/action-policies/action-policy-reference.md
Manage action policies View and edit, enable/disable/snooze, maintenance windows, rotate API keys, bulk actions explore-analyze/alerting/kibana-alerting-experimental/action-policies/manage-action-policies.md
Review action policy execution history Execution history columns, search and filter, dispatch outcomes reference, unmatched caveat explore-analyze/alerting/kibana-alerting-experimental/action-policies/review-execution-history.md
Reduce notification noise Acknowledge, snooze, mark inactive, and maintenance windows to reduce noise explore-analyze/alerting/kibana-alerting-experimental/action-policies/reduce-notification-noise.md

Action policy scenarios

Page name Description File ✏️ Ready for editorial review 🔧 Ready for technical review
Action policy scenarios Index page: introduces the section and links to three scenario sub-pages explore-analyze/alerting/kibana-alerting-experimental/action-policies/common-action-policy-scenarios.md
Route alert episodes by severity How to direct critical and non-critical episodes to different workflows using severity-scoped policies explore-analyze/alerting/kibana-alerting-experimental/action-policies/route-by-severity.md
Manage severity escalation notifications How policies match and re-match episodes as severity shifts; controlling which notifications fire on escalation and de-escalation explore-analyze/alerting/kibana-alerting-experimental/action-policies/severity-escalation.md
Re-notify for persistently active episodes How to use time-based throttles to send follow-up notifications when an episode stays active without a status change explore-analyze/alerting/kibana-alerting-experimental/action-policies/re-notification.md

Workflows (updated pages)

Page name Description File ✏️ Ready for editorial review 🔧 Ready for technical review
Triggers Updated to include rule lifecycle trigger family, use cases, and context fields explore-analyze/workflows/triggers.md
Event-driven triggers New rule lifecycle triggers section: five trigger types, schema, event payload, and audit workflow example explore-analyze/workflows/triggers/event-driven-triggers.md

Note on toc.yml conflicts: Merge PRs in order and resolve toc.yml conflicts at each step.

Generative AI disclosure

  1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?
  • Yes — Cursor + Claude
  • No

@github-actions

Copy link
Copy Markdown
Contributor

Elastic Docs AI PR menu

Check the box to run an AI review for this pull request.

  • Review docs changes (docs-review). Status: not started.

Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team.

@nastasha-solomon nastasha-solomon marked this pull request as draft May 15, 2026 20:17
@github-actions

github-actions Bot commented May 15, 2026

Copy link
Copy Markdown
Contributor

@github-actions

github-actions Bot commented May 15, 2026

Copy link
Copy Markdown
Contributor

Elastic Docs Style Checker (Vale)

Summary: 3 warnings, 15 suggestions found

⚠️ Warnings (3): Fix when the suggestion improves clarity or correctness.
File Line Rule Message
explore-analyze/alerting/kibana-alerting-experimental/workflows-alerting.md 13 Elastic.EndPuntuaction Don't end headings with punctuation.
explore-analyze/alerting/watcher/actions.md 150 Elastic.QuotesPunctuation Place punctuation inside closing quotation marks.
explore-analyze/workflows/triggers/event-driven-triggers.md 362 Elastic.Spelling 'unsnoozed' is a possible misspelling.
💡 Suggestions (15): Optional style improvements. Apply when helpful.
File Line Rule Message
explore-analyze/alerting/kibana-alerting-experimental/action-policies/about-action-policies.md 71 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/action-policies/action-policy-reference.md 87 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/action-policies/create-configure-action-policy.md 59 Elastic.WordChoice Consider using 'efficient, basic' instead of 'simple', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/action-policies/create-configure-action-policy.md 63 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/action-policies/manage-action-policies.md 8 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/action-policies/manage-action-policies.md 13 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/action-policies/manage-action-policies.md 19 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/action-policies/manage-action-policies.md 21 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/action-policies/review-execution-history.md 45 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/kibana-alerting-experimental/notifications-actions.md 36 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/alerting/watcher/actions.md 150 Elastic.FirstPerson Use caution when using first-person pronouns such as 'me.'
explore-analyze/workflows/triggers/event-driven-triggers.md 407 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/workflows/triggers/event-driven-triggers.md 410 Elastic.WordChoice Consider using 'deactivated, deselected, hidden, turned off, unavailable' instead of 'disabled', unless the term is in the UI.
explore-analyze/workflows/triggers/event-driven-triggers.md 412 Elastic.WordChoice Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.
explore-analyze/workflows/triggers/event-driven-triggers.md 436 Elastic.WordChoice Consider using 'deactivated, deselected, hidden, turned off, unavailable' instead of 'disabled', unless the term is in the UI.

The Vale linter checks documentation changes against the Elastic Docs style guide. To use Vale locally or report issues, refer to Elastic style guide for Vale.

Adds six pages under kibana-alerting-experimental/:
- workflows-alerting.md: workflow overview and runtime execution order
- notifications.md: action policy overview with dispatcher behavior
- notifications/create-configure-action-policy.md: creation guide
- notifications/action-policy-reference.md: full field reference
- notifications/manage-action-policies.md: management operations
- notifications/notification-gating.md: acknowledge/snooze/deactivate gating

Incorporates additions from PR #6395 including the new notification-gating page.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
@nastasha-solomon nastasha-solomon self-assigned this May 15, 2026
@nastasha-solomon nastasha-solomon changed the title Add experimental alerting features workflows and notifications pages [Alerting V2][Serverless & 9.5][M2] Add experimental alerting features workflows and notifications pages May 18, 2026
…6639)

<!--
Thank you for contributing to the Elastic Docs! 🎉
Use this template to help us efficiently review your contribution.
-->

## Summary
<!--
Describe what your PR changes or improves.  
If your PR fixes an issue, link it here. If your PR does not fix an
issue, describe the reason you are making the change.
-->

Updates the action policy docs for the experimental alerting features
with content from eight doc issues. Following the tech preview principle
of accuracy over comprehensiveness, changes focus on stable concepts and
system behavior rather than UI details that are subject to change.

### Per-rule action policies
([#6613](#6613))

The most significant conceptual change in this batch. The previous docs
described all action policies as global within a space. PR #268006
introduced a `global` / `single_rule` type discriminator, making the
existing description factually incorrect.

**`notifications.md`** — Updated "What is an action policy" to define
both policy types, their scoping rules, and when to use each. Updated
"How policies apply to rules" to distinguish global and per-rule
scoping. Updated "Why policies are separate from rules" to reflect that
per-rule policies exist for rule-specific routing.

**`create-configure-action-policy.md`** — Added a **Policy type** field
section explaining the global/per-rule distinction, the immutability
constraint, and when to choose each type. Updated the opening paragraph
and the match conditions scope description to reflect both types.

### Policy tags
([#6616](#6616))

PR #261008 added a `tags` field to notification policies across the full
stack.

**`create-configure-action-policy.md`** — Added a **Tags** field section
explaining that policy tags are organizational labels distinct from rule
tags and do not affect routing behavior.

### Quick filter KQL fields
([#6608](#6608))

PR #261601 added Rule, Status, and Tags quick filter pickers to the
match conditions form. The pickers generate `rule.id`, `episode_status`,
and `rule.tags` KQL respectively.

**`action-policy-reference.md`** — Added `rule.tags` to the match
conditions field reference table. This field was missing but is now
surfaced by the quick filters and used in examples across the docs.

**`create-configure-action-policy.md`** — Updated the match conditions
example from `data.severity` to `rule.tags: "payment-service"` to
reflect the fields that quick filters generate.

### Maintenance window suppression
([#6416](#6619))

PR #267771 added backend suppression logic for maintenance windows in
the dispatcher.

**`action-policy-reference.md`** and **`notifications.md`** — Updated
the `suppressed` dispatch outcome description to include maintenance
windows as a cause alongside acknowledge, snooze, and deactivate.

### View policy details
([#6419](#6619))

PR #264497 added a details flyout to the Action policies list page.

**`manage-action-policies.md`** — Added a "View policy details" section
describing that a policy's full configuration and all per-policy actions
are accessible from the list page. UI mechanics (flyout vs. dedicated
page) are omitted as the IA is not yet stable.

### Policy execution history
([#6501](#6501))

PR #266775 added a Policy Execution History UI and API.

**`manage-action-policies.md`** — Added an "Execution history" section
describing how to query dispatch outcomes per policy using the
`.alert-actions` data stream. The section points to the existing
dispatch outcomes reference rather than documenting the UI, which is
subject to change.

### Out of scope for this PR

- **[#6498](#6498
(optional `matcher` query parameter on the data fields suggestions
endpoint): API reference detail with no conceptual home yet.
- **[#6617](#6617
(grouping modes and frequency strategies redesign): The existing
reference and create-configure pages already cover this content
accurately. No new stable concepts to add at the tech preview stage.

## Generative AI disclosure
<!--
To help us ensure compliance with the Elastic open source and
documentation guidelines, please answer the following:
-->
1. Did you use a generative AI (GenAI) tool to assist in creating this
contribution?
- [x] Yes - Cursor + Claude  
- [ ] No  
<!--
2. If you answered "Yes" to the previous question, please specify the
tool(s) and model(s) used (e.g., Google Gemini, OpenAI ChatGPT-4, etc.).

Tool(s) and model(s) used:
-->
@nastasha-solomon nastasha-solomon marked this pull request as ready for review May 27, 2026 02:14
@nastasha-solomon nastasha-solomon requested a review from a team as a code owner May 27, 2026 02:14
@nastasha-solomon nastasha-solomon requested a review from kdelemme May 27, 2026 02:14
Comment thread explore-analyze/alerting/kibana-alerting-experimental/notifications.md Outdated
Comment thread explore-analyze/alerting/kibana-alerting-experimental/notifications.md Outdated
Comment thread explore-analyze/alerting/kibana-alerting-experimental/notifications.md Outdated
Comment thread explore-analyze/alerting/kibana-alerting-experimental/notifications.md Outdated
…tions.md

Co-authored-by: Kevin Delemme <kdelemme@gmail.com>
@nastasha-solomon nastasha-solomon marked this pull request as ready for review July 2, 2026 04:02
@nastasha-solomon nastasha-solomon requested a review from a team as a code owner July 2, 2026 04:02
nastasha-solomon added a commit that referenced this pull request Jul 2, 2026
…ontent (#7180)

## Summary

Preps the experimental alerting system overview page and related pages
for incoming content from PRs #6523 (rules), #6525 (notifications and
action policies), and #6527 (alerts). Changes follow the principle of
reducing duplication and orienting the overview page toward routing
readers forward rather than documenting the full system end-to-end.

## Changes

### `kibana-alerting-experimental.md`

**Glossary extracted to a dedicated page.** The glossary section (60+
lines) has been moved to `kibana-alerting-experimental/glossary.md` and
replaced with a two-line cross-reference. Keeping it on the overview
caused the page to function as both a conceptual introduction and a
reference, which made it harder to scan. The dedicated page allows the
overview to stay focused.

**"How the pieces fit together" section trimmed.** The six-step numbered
list in Alert mode and the three-step numbered list in Signal mode have
been replaced with 2–3 prose sentences each. The same content is
documented in `about-action-policies.md` (PR #6525); keeping a full
numbered flow on the overview created duplicate maintenance surface. The
diagrams and worked examples are retained.

**Examples made collapsible.** The Alert mode and Signal mode worked
examples are now wrapped in `::::{dropdown}` directives. This keeps the
examples available for readers who want them without making them a
required part of the overview flow.

**Terminology note added.** A callout clarifies that *alert* (classic
Kibana alerting) and *alert episode* (experimental system) describe
similar ideas in different systems and are not interchangeable. This
addresses terminology friction for readers who use both systems.

**"Four building blocks" sub-sections annotated for post-merge
trimming.** Each sub-section has a TODO comment identifying what to cut
and which child page to link to once the corresponding PR merges. The
content is unchanged for now since the child pages don't yet exist on
main.

**"Next steps" section prepped for post-merge replacement.** A TODO
comment in Next Steps contains the three forward-facing tracks (Rules,
Alerts, Notifications) ready to swap in once PRs #6523, #6525, and #6527
merge. Currently the section still points to the parent alerting page
and the choose-an-alerting-system page.

### `kibana-alerting-experimental/glossary.md` (new)

New page containing all glossary terms with 1-sentence definitions. TODO
comments are in place for each term's "To learn more" cross-link,
pointing to the correct child pages in the incoming PRs. Link paths are
relative to the glossary's location in the subdirectory.

### `alerts.md`

**Terminology note added.** A callout mirrors the one on the overview
page, telling readers that what this doc calls *alerts* are called
*alert episodes* in the experimental system. Placed after the existing
experimental system cross-reference callout.

### `choose-an-alerting-system.md`

**TODO comment added after the comparison table.** Documents which
comparison table cells should gain cross-links to child pages once PRs
#6523, #6525, and #6527 merge, with the specific target file for each
row.

### `toc.yml`

Added `glossary.md` as a child of `kibana-alerting-experimental.md`.

## Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this
contribution?
- [x] Yes — Cursor + Claude
- [ ] No

@doakalexi doakalexi left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

technical review LGTM!

nastasha-solomon added a commit that referenced this pull request Jul 3, 2026
## Summary

Updates `setup-alerting.md` and `alerting-privileges.md` for the
experimental alerting system with the confirmed M2 enablement procedure
and RBAC privilege requirements. Following the tech preview principle of
accuracy over comprehensiveness, additions focus on stable behavior —
how to turn the feature on, what the setting controls, what happens when
it's turned off, and which privilege controls which action.

---

## Content changes

### RBAC privilege requirements (closes #6043)

Kibana PRs #270574 and #272440 introduced four standalone privileges
under the **Alerting** category in Kibana role management: **Rules**,
**Alerts**, **Action Policies**, and **Execution history**. Each
privilege is independent; holding one does not grant another.

**`alerting-privileges.md`** — Replaced all four `[CONTENT NEEDED]`
placeholders with full privilege documentation:

* **Manage rules** — privilege table (All: create, edit, delete, enable,
and disable rules; Read: view rules) with guidance on when each level
applies.
* **Manage action policies** — privilege table (All: create, update,
delete, snooze, and unsnooze; Read: view) with an explicit callout that
**Rules: All** does not include action policy management.
* **Manage alerts** — privilege table (All: acknowledge, snooze, assign,
tag, activate, and deactivate alert episodes; Read: view) with triage
use case.
* **View execution history** — new section documenting that both All and
Read grant identical read-only access. There is no write surface for
execution history.
* **Query alert data in Discover** — Kibana **Discover: Read** access
plus `read` index privilege on `.rule-events` and `.alert-actions`, with
a note to use a custom role for hidden system data streams.

Also updated the opening paragraph from "control which users can" to
"control what you can do with" to use second-person voice, consistent
with the style applied across the other sections.

What was omitted: role management UI steps (subject to change before
GA), specific custom role configuration procedures, and any
serverless-specific privilege differences not yet confirmed.

---

### Enable the experimental alerting system (closes
elastic/docs-content-internal#1113)

Kibana PR #272365 consolidated experimental alerting feature flags under
a single `alerting:v2:enabled` advanced setting.

**`setup-alerting.md`** — Replaced the "CONTENT NEEDED" placeholder in
the **Enable the experimental alerting system** section with the
confirmed M2 enablement procedure:

* **Stack path**: Stack Management → Advanced Settings → Global settings
→ toggle on **alerting:v2:enabled**.
* **Serverless path**: No Global Advanced Settings UI exists in
serverless. Documents the `POST kbn:/internal/kibana/global_settings`
Dev Tools call with a note that the endpoint is internal and has no
public equivalent.
* **Disabled-state behavior**: When the setting is off, rule and
dispatcher execution stops, the APIs and UIs are hidden, and existing
rules and action policies are paused. Turning it back on resumes
execution. Disabling does not delete any data.

What was omitted: the `kibana.yml` prerequisite (configured by default;
no action needed), non-YAML UI steps for serverless (no UI exists), and
the internal Kibana issue tracking the default enablement
(elastic/rna-program#606).

### Stale CONTENT NEEDED comment removed

**`setup-alerting.md`** — Removed the "CONTENT NEEDED" comment from the
**Where rule events are stored** section. The comment flagged
uncertainty about whether `.rule-events` and `.alert-actions` would be
the intended query surface for end users. This is now confirmed: both
data streams are the documented query surface, as reflected in the
[Query alert history in
Discover](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6527/explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover)
page in PR #6527.

### Stale TODO paths fixed

**`setup-alerting.md`** — Fixed two broken cross-reference paths in the
commented-out **Next steps** links:

* `rules/author-rules.md` → `rules/create-a-rule.md`. The
`author-rules.md` page was deleted in PR #6523; `create-a-rule.md` is
the new entry point to the rules section.
* `notifications/create-configure-action-policy.md` →
`action-policies/create-configure-action-policy.md`. The directory
structure for action policies changed in PR #6525.
* Updated "Detect or Alert mode" → "Signal or Alert mode" to match the
renamed rule kind label from PR #6523.

### Opening intro updated

Removed the "Set up is part of the experimental alerting system in
Kibana" anchor sentence and split the opening paragraph in two for
scannability. Updated "need to be enabled" to "must be enabled" for
imperative clarity.

---

## Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this
contribution?
* Yes — Cursor + Claude
* No
nastasha-solomon added a commit that referenced this pull request Jul 5, 2026
…; 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

@miguelmartin-elastic miguelmartin-elastic left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a couple of comments. The main one is regarding the recent changes in the Execution History page. Let me know if I can help with anything. TIA!


Episodes that were acknowledged, snoozed, marked inactive, or covered by a maintenance window are suppressed before the dispatcher runs and produce no event log entry.

`unmatched` appears in the event log but isn't available as an outcome filter in the **Execution history** UI. To find `unmatched` records, open Discover, query `.kibana-event-log-*`, add a filter for `event.provider: "alerting_v2"`, and filter `event.action: "unmatched"`.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Comment thread explore-analyze/workflows/triggers/event-driven-triggers.md Outdated
|---|---|
| **Timestamp** | When the dispatcher ran. |
| **Policy** | The action policy that was evaluated. |
| **Rule** | The rule whose alert episodes the policy processed. |

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As mentioned here, this column is now plural "Rules"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants