Repository navigation
[Alerting V2] Document 9.6 GA without version-split experimental content - #9019
nastasha-solomon wants to merge 8 commits into
Conversation
Alerting V2 is GA on serverless and in 9.6, so the Alerting V2 pages now describe only GA behavior. The page-level applies_to tag (stack: ga 9.6+, experimental =9.5) is the only place 9.5 still appears, which tells readers the system was experimental in 9.5. Removes 9.5-only content: the 9.5 tabs in applies-switch blocks, the episode_id and episode_status fields, query.format, metadata.owner, artifacts[].value, recovery_strategy, no_data_strategy, the flat state_transition.pending_* fields, action policy tags, rule fields in Match conditions, the rule-form notification flow, and the Alerting V2 Preview navigation path. Removes the 9.5 upgrade warning for Match conditions, since 9.5 breaking changes don't need documenting. Removes redundant serverless: ga and stack: ga 9.6+ badges that only contrasted GA content with 9.5. Updates the workflow trigger pages to drop the 9.5 trigger IDs and event.episodeId, and tags alert and rule lifecycle triggers as preview 9.6+. Kibana registers them as tech_preview. Updates the Universal Alerting row in Kibana privileges to drop the 9.5 naming note. Keeps the GA badges there because that page covers all stack versions. Co-authored-by: Cursor <cursoragent@cursor.com>
Elastic Docs AI PR menuCheck the box to run an AI review for this pull request.
Powered by GitHub Agentic Workflows and docs-actions. For more information, reach out to the docs team. |
Elastic Docs Style Checker (Vale)Summary: 2 warnings, 1 suggestion found
|
| File | Line | Rule | Message |
|---|---|---|---|
| explore-analyze/workflows/triggers/event-driven-triggers.md | 472 | Elastic.Spelling | 'unresolves' is a possible misspelling. |
| explore-analyze/workflows/triggers/event-driven-triggers.md | 475 | Elastic.Spelling | 'unsnoozed' is a possible misspelling. |
💡 Suggestions (1): Optional style improvements. Apply when helpful.
| File | Line | Rule | Message |
|---|---|---|---|
| explore-analyze/alerting/esql/get-started/create-your-first-rule.md | 292 | Elastic.Ellipses | Use ellipses sparingly. Remove the ellipsis unless it appears in UI text. |
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.
Goes fully GA-only, as proposed in elastic/docs-content-internal#2079. Changes stack: ga 9.6+, experimental =9.5 to stack: ga 9.6+ in the Alerting V2 page frontmatter and in the related-page badges (alerting.md, alerts.md, compare-alerting-systems.md, and detect-and-alert.md). Drops experimental =9.5 from the workflow lifecycle trigger badges, and moves the Agent Builder tags from experimental 9.5+ to experimental 9.6+. Adds the upgrade note from the issue to the overview and setup pages. The note tells anyone who tried the experimental version in 9.5 to upgrade to 9.6. On the overview page, the note joins the existing Classic Alerting note rather than stacking a second admonition. Co-authored-by: Cursor <cursoragent@cursor.com>
Checks the tutorial against Kibana main and updates it to match the GA rule form: - Removes the deployment-type requirement and the "turned on" requirement. Universal Alerting is on by default. - Adds a serverless-only requirement for an Observability project, because Kibana hides Universal Alerting in Elasticsearch and Security projects. - Opens the rule form through Create rule > ES|QL rule, and the sandbox through Add query. - Splits configuration into the Condition step (schedule and lookback) and the Outcome step (goal, alert delay, and recovery). Removes the Mode field, which no longer exists. - Searches for the rule in Execution history instead of selecting it, and names the Trend chart on the alert details page. Co-authored-by: Cursor <cursoragent@cursor.com>
Condenses the requirements to two bullets: an Elastic Stack deployment or an Observability project on Serverless, and the privileges needed for the tutorial. Removes the inline serverless badge so the deployment requirement covers both deployment types without version numbers. Co-authored-by: Cursor <cursoragent@cursor.com>
…counts Setup page: - Removes the "Turn on the system" section. Universal Alerting is on by default. - Groups the three advanced settings under one section with a summary table of scope and default. - Renames the turn-off section to "Opt out of Universal Alerting", moves it to the end, and rewrites it as numbered steps with a short summary of what turning it off does and doesn't do. - Describes experimental features in general terms instead of listing each one. - Clarifies how the new Alerts page differs from the Classic-only Observability Alerts page, and names the setting that keeps it. - Shortens the requirements and intro, and points Next steps only to the first-rule tutorial. Other pages: - Replaces "three alerting systems" on the alerting overview and the compare page with wording that doesn't depend on a fixed count. - Updates the setup page summaries on the overview and how-it-works pages. Co-authored-by: Cursor <cursoragent@cursor.com>
bmorelli25
left a comment
There was a problem hiding this comment.
Very clean 👍. One thing to fix.
|
|
||
| ## Requirements [create-rule-requirements] | ||
|
|
||
| Before you start, make sure you have the following: |
There was a problem hiding this comment.
If I had to complain, I would complain that the changes in this file probably could've been in a separate PR 😛
There was a problem hiding this comment.
That's fair! I just wanted to get the tutorial changes in asap
| Go to **Alerting** → **Rules** in the {{observability}} navigation menu, or find **Rules** using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). | ||
|
|
||
| Then create a new rule, and select **Create ES|QL rule** to open the rule authoring flyout. | ||
| Select **Create rule**, then select **ES|QL rule** to open the rule form. |
shainaraskas
left a comment
There was a problem hiding this comment.
would we want to keep the experimental tag on the core feature so people know it was available but experimental then?
ok either way - just a thought
🏁 for the one admin docs file

Summary
Fixes https://github.com/elastic/docs-content-internal/issues/2079.
The Alerting V2 docs now describe only the 9.6 GA version. The system was experimental for one minor (9.5) and changed a lot before GA, so this PR removes the 9.5 content instead of keeping it next to the GA content.
This PR doesn't document the breaking changes between 9.5 and 9.6. Experimental features have no compatibility promises, and the 9.5 release notes still cover the experimental release.
Changes
Version tags
applies_totostack: ga 9.6+by droppingexperimental =9.5. The related-page badges inalerting.md,alerts.md,compare-alerting-systems.md, anddetect-and-alert.mdget the same change.preview 9.6+, to match theirtech_previewregistration in Kibana.experimental 9.5+toexperimental 9.6+.Removed 9.5 content
applies-switchblock with only its GA content.episode_id/episode_status,query.format,recovery_strategy,no_data_strategy, action policy tags, rule fields in Match conditions, the rule-form notification flow, and the Alerting V2 Preview navigation path.event.episodeIdfrom the workflow trigger pages.Page updates
main.Preview
Generative AI disclosure