Investigate alert episodes in the experimental alerting system

This page explains what information is available on the episode detail page in the experimental alerting system and how to use it to understand what triggered an episode, assess its severity, identify recurring patterns, and coordinate a response.

Each episode includes key context to answer the first questions in any investigation:

• Grouping - The value of the BY clause that identifies this episode's group, such as a hostname or service name. Use it to confirm which entity the rule is firing on.
• Triggered - When the episode opened.
• Duration - How long the episode has been active.
• Assignee - Who currently owns the episode, if anyone.

The Rule overview section shows the rule name, type, and status alongside a snippet of its ES|QL query. Select View rule details to open the full rule configuration and confirm exactly what condition the rule evaluates.

Each episode shows a trend chart comparing the evaluated metric against the rule's threshold conditions over the episode's lifetime. Use it to understand how far the metric exceeded the threshold, whether the breach was escalating or stabilizing, and when it peaked.

When a rule includes multiple threshold conditions:

• Conditions that compare the same metric appear together, with each threshold represented separately.
• Conditions that compare different metrics appear in separate views, one for each metric.

This chart only appears when the system can parse threshold conditions from the rule's query. It doesn't appear for signal-mode rules or rules whose query doesn't contain extractable threshold comparisons.

The episode timeline shows its full duration as a horizontal bar, from when it was triggered to its most recent evaluation or close time.

Related episodes from the same rule are grouped to help you answer whether this is an isolated incident or part of a larger pattern:

• Same alert group - Episodes for this rule that share the same group as the current episode (same group_hash). A long list here suggests the underlying condition isn't being fully resolved between episodes.
• Other groups for this rule - Episodes from the same rule firing on different entities (different group_hash). Use this to gauge how broadly the rule is triggering across your environment.

Each episode tracks who performed the most recent response action of each type, so you can avoid duplicating work or missing a step someone else already handled:

• Acknowledged by - The user who most recently acknowledged the episode.
• Resolved by - The user who most recently resolved or deactivated the episode.
• Snoozed by - The user who snoozed the episode, shown together with the Snoozed until time.

These rows only appear when the episode is in the corresponding state. System-generated actions display as System.

Each episode includes a metadata view that surfaces the field values computed or retained by the rule's ES|QL query. For example, a query using STATS ... BY stores aggregated values, not all fields from the underlying events. Use it to inspect rule-specific context such as resource identifiers or computed metrics. You can search by field name or value and toggle off null fields to focus on populated data.

If the rule has a runbook URL configured, you can access it directly from the episode to follow documented response procedures.

Assign an episode to a user to establish ownership and prevent duplicate work when multiple people are reviewing the same queue. Only one user can hold the assignment at a time; assigning replaces any existing assignee.