---
title: Investigate alert episodes in the experimental alerting system
description: Investigate alert episodes in the experimental alerting system. Understand what triggered an alert episode, assess metric behavior, find related alert episodes, review responders, and inspect underlying data.
url: https://www.elastic.co/elastic/docs-builder/docs/4116/explore-analyze/alerting/experimental-alerting-system/alerts/investigate-alert-episodes
products:
  - Kibana
applies_to:
  - Elastic Cloud Serverless: Experimental
  - Elastic Stack: Experimental since 9.5
---

# Investigate alert episodes in the experimental alerting system
From the **Alerts** page, select an alert episode to open its detail page, which surfaces what triggered the alert episode, its severity, recurring patterns, and response history, so you can investigate and coordinate a response.

## Understand the trigger and scope

Each alert episode includes key context to answer the first questions in any investigation:
- **Grouping** - The value of the `BY` clause that identifies this alert episode's group, such as a hostname or service name. Use it to confirm which entity the rule is firing on.
- **Triggered** - When the alert episode opened.
- **Duration** - How long the alert episode has been active.
- **Assignee** - Who currently owns the alert episode, if anyone. To assign or reassign the alert episode, refer to [Triage alert episodes](https://www.elastic.co/elastic/docs-builder/docs/4116/explore-analyze/alerting/experimental-alerting-system/alerts/triage-alert-episodes).

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.

## Assess the metric behavior

Each alert episode shows a trend chart comparing the evaluated metric against the rule's threshold conditions over the alert 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 appears only for rules that group matches into an alert episode and whose query contains extractable threshold comparisons.
The alert episode timeline shows its full duration as a horizontal bar, from when it was triggered to its most recent evaluation or close time.

## Check for related or recurring alert episodes

Related alert 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** - Alert episodes for this rule that share the same group as the current alert episode (same `group_hash`). A long list here suggests the underlying condition isn't being fully resolved between alert episodes.
- **Other groups for this rule** - Alert 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.


## Review who has responded

Each alert 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 alert episode.
- **Resolved by** - The user who most recently resolved the alert episode.
- **Snoozed by** - The user who snoozed the alert episode, shown together with the **Snoozed until** time.

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

## Inspect the underlying data

Each alert 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.
<tip>
  Use the **Open in Discover** action to view the full source documents instead of these computed values. The action runs the rule's base query in Discover, aligned with the alert episode's timeframe. Once there, adjust the query to see what you need. For example, remove the aggregation to return source documents instead of aggregated output.
</tip>


## Access the response runbook

If the rule has a runbook attached, you can view it directly from the alert episode to follow the documented triage steps.