View and manage alerts

When a rule detects a problem, use the Alerts UI to understand what's happening and decide what to do about it. From here you can examine alert episodes, use filters to find what needs attention, triage alerts, and more. This is the operational surface for working through alerts day to day.

• Rule: Limit rows to one or more rules.
• Status: Limit by episode lifecycle state (active, recovered, pending, inactive).
• Tags: Limit to episodes whose last tag set matches any selected tag (OR logic). Tag choices come from tag actions in the selected time range.
• Search: Text search runs over alert event document fields. Combine with Rule or Tags filters when looking for a specific rule or label.

Narrow the time range when filters return too many rows or when tag options need refreshing.

From any row in the table you can:

• Acknowledge / Unacknowledge: Applies to the individual episode.
• Snooze / Unsnooze: Applies to the group (group_hash), so all rows sharing that group are affected.
• Resolve / Unresolve: Applies to the group. The episode shows as inactive in the UI when resolved, even if the underlying lifecycle data has not yet caught up.
• Edit tags: Opens a flyout to add tags; persisted as tag actions in .alert-actions.

The same actions are available from the episode detail page.

Select Discover on a row to investigate source data. Discover opens with the rule ES|QL query and a short time window around the episode so you can inspect matching documents in context.

For ad hoc analysis over .rule-events and .alert-actions with copy-paste ES|QL examples, refer to Query alerts and signals in Discover.

Open an episode's detail page by selecting its name or ID from the table row. The detail page shows:

• Lifecycle: A state-over-time visualization (pending, active, recovering, inactive) driven by events in .rule-events.
• Actions and metadata: Tags and action-driven status (acknowledge, snooze, resolve) consistent with the episodes table.
• Related episodes: Other episodes on the same rule or series.
• Grouping: When the rule uses grouping, the detail view surfaces the field values that identify the series.

When you take an action, Kibana writes a document to the .alert-actions data stream. You can query these documents in Discover for auditing and metrics such as mean time to acknowledge (MTTA). For a full field list and state definitions, refer to Alert states and fields reference.

Some actions apply only to the specific episode you acted on. Others apply to every episode in the same group, meaning all episodes that share the same rule and series. This matters when a rule tracks multiple services or hosts. Snoozing one episode silences the whole group, not only that service.

Suppression controls whether a matched alert episode actually sends a notification. The dispatcher evaluates suppression before any action policy matcher runs, so a suppressed episode never reaches routing, grouping, or throttle checks. Mechanically, each suppression option is stored as a separate document type in .alert-actions, and the dispatcher runs a targeted query scoped to only the relevant (rule_id, group_hash) pairs from the current evaluation — rather than re-reading the entire .rule-events index — to keep dispatch evaluation efficient at high episode volumes.

There are three suppression options, each with a different scope: