[Alerting V2][Serverless & 9.5][M2] Alert changes from June 22, 2026

[nastasha-solomon]

Summary

Updates alerting docs for the experimental alerting system with content from five M2 doc issues, plus a structural restructuring of the alerts documentation set. Following the tech preview principle of accuracy over comprehensiveness, additions focus on stable concepts — what these features help users understand, when to use them, and how they fit into the system.

---

Structural changes

view-and-manage-alerts.md split into three pages

The original page covered too many distinct tasks in a single file. It has been split into:

• view-and-manage-alerts.md (retained as parent) — Now scoped to the overview of the Alerts UI: space scoping, KPI panels, episode histogram, and filter/search. Links forward to the two child pages.
• triage-alert-episodes.md (new) — Covers all triage actions: acknowledge, snooze, resolve, activate, edit tags, assign, bulk actions, Open in Discover, and the action scope reference table.
• investigate-alert-episodes.md (new) — Covers the episode detail page: metric trend, related episodes by series, source event metadata, response history and actors, and episode assignment.

alert-states-and-fields-reference.md renamed to field-reference.md

Renamed to better reflect the page's purpose as a field schema reference rather than a state reference. New H1 title: "Alert data stream field reference". The standalone status values section was removed; status values and accepted values are now documented inline in each field's description column. Both tables were updated from four columns to three (Field, Type, Description) following standard reference conventions.

alert-data-model.md added (moved from alerts.md)

The "Where alerts live" and "Signals versus alerts" content was extracted from alerts.md into a new dedicated page explaining the foundational data model: what the system writes, where it writes it (.rule-events and .alert-actions), and how rule mode determines whether a document is a signal or an alert.

toc.yml restructured

The nav hierarchy now reflects the logical grouping of pages:

alerts.md
├── view-and-manage-alerts.md
│   ├── triage-alert-episodes.md
│   └── investigate-alert-episodes.md
└── query-alerts-and-signals-in-discover.md
    ├── alert-data-model.md
    └── field-reference.md

---

Content changes

Metric trend for threshold rules on the episode detail page (#7160)

Kibana PR #275034 adds a trend panel to the episode detail page that plots the metric values evaluated by a rule over the episode's time range, alongside the threshold values from the rule conditions. The panel is only present for threshold-based rules.

alerts/investigate-alert-episodes.md — Added a "Metric trend" section documenting: what the trend view shows (evaluated metric versus threshold conditions over the episode's lifetime), the multi-condition grouping behavior (same metric → combined view; different metrics → separate views per metric), and the conditional visibility rule (absent for signal-mode rules and rules without comparable metric output).

What was omitted: panel position relative to other elements, visual styling of threshold lines, badge selector UI for switching between metrics, and flyout versus full-page behavior differences.

Histogram chart and KPI panels on the alert episodes list (#6872, #6876)

PR #270922 added a histogram chart above the alert episodes table. PR #271147 added two KPI stat panels to the same page.

alerts/view-and-manage-alerts.md — Added a "Monitor alert health and trends" section covering KPI panels (aggregate counts that update as filters change) and the episode histogram (trend over time, breakdown by dimensions). Includes a :::note block for the 10,000-episode query cap. A <!-- CONTENT NEEDED --> comment flags that specific KPI panel labels and layout should be documented once the UI stabilizes before GA.

What was omitted: specific KPI metric labels by panel name, all histogram breakdown option names, color coding for status badges, and URL persistence of selections.

Discover Alerts menu access and v2 flyout routing (#6878, #7010)

PR #267469 fixed a bug where the Discover Alerts menu was hidden for users with only {{alerting-v2-system}} access. PR #272724 redesigned the Alerts menu and routes rule creation to the v2 rule form when {{alerting-v2-system}} is enabled.

alerts/query-alerts-and-signals-in-discover.md — Added a "Create rules from Discover" section covering the access rule (either Kibana alerting access or {{alerting-v2-system}} access is sufficient) and the routing behavior. A <!-- CONTENT NEEDED --> comment calls for step-by-step instructions once the rules page is written.

What was omitted: specific redesigned menu structure, screenshots, and detailed creation steps.

Query page improvements

alerts/query-alerts-and-signals-in-discover.md — Multiple improvements throughout:

• Added a complete "Before you begin" procedure for creating .rule-events and .alert-actions data views in Discover, sourced from the existing data views docs with a cross-link.
• Rewrote section intros in active voice (attribution to Kibana, not the data streams).
• Converted all example queries from bold-label format to #### subsections with descriptive titles, introductory sentences, and inline // comments annotating each meaningful query line.
• Updated the "Trace the full story of an incident" section to document the episode_id optionality caveat (system-written action types may not carry episode_id), explain the naming difference between episode.id and episode_id, and recommend group_hash as the more reliable join key.

---

Generative AI disclosure

1. Did you use a generative AI (GenAI) tool to assist in creating this contribution?

• Yes — Cursor + Claude
• No

[github-actions]

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.