You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Alerting v2 core engine now reacts immediately (via the dispatcher, not waiting for the next rule execution) when a user activates or deactivates an episode via UI or API. Key behavioral decision: once a user activates an episode, the engine keeps it open and ignores automatic recoveries for that episode until the user manually closes it; deactivating lets a new episode open on the next breach.
Why this needs docs: triage-alert-episodes.md (PR #6527) documents 'Activate: Manually moves the episode to active state without waiting to meet the activation threshold' but doesn't mention the critical follow-on behavior that an activated episode is then exempted from automatic recovery and must be manually closed — an omission a user needs to know to avoid assuming the episode will auto-resolve normally.
Resources
PR #274618 — [Alerting v2] Take into account activated/deactivated episodes in the core engine
What the docs say: "Activate: Manually moves the episode to `active` state without waiting to meet the activation threshold." No mention of what happens to the episode's automatic recovery behavior after manual activation.
What to add: This page (still in open docs-content PR [Alerting V2][Serverless & 9.5][M2] Add experimental alerting features alerts pages #6527) describes the Activate action but doesn't state that once an episode is manually activated, the engine ignores automatic recoveries for it and it stays open until manually deactivated/closed — user intention takes priority over the rule's own recovery detection. Without this, a user could reasonably expect the episode to auto-recover normally like any other active episode. Applies from 9.5.0 (experimental) and in serverless (experimental).
Summary
The Alerting v2 core engine now reacts immediately (via the dispatcher, not waiting for the next rule execution) when a user activates or deactivates an episode via UI or API. Key behavioral decision: once a user activates an episode, the engine keeps it open and ignores automatic recoveries for that episode until the user manually closes it; deactivating lets a new episode open on the next breach.
Why this needs docs: triage-alert-episodes.md (PR #6527) documents 'Activate: Manually moves the episode to active state without waiting to meet the activation threshold' but doesn't mention the critical follow-on behavior that an activated episode is then exempted from automatic recovery and must be manually closed — an omission a user needs to know to avoid assuming the episode will auto-resolve normally.
Resources
code/detailsfromBoom.dataare dropped from 4xx/5xx response bodies kibana#274951Availability
Created with Docs Quest Scanner by @nastasha-solomon
Suggested edits
Triage alert episodes > Available actions