From 3affcb108057a90b3c0b0a5c61cd098c6ff2f0b3 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon Date: Fri, 15 May 2026 16:46:11 -0400 Subject: [PATCH 1/2] Add experimental alerting features alerts pages Adds four pages under kibana-alerting-experimental/alerts/: - alerts.md: section index covering alert lifecycle and .alert-actions - alerts/view-and-manage-alerts.md: triage, acknowledge, snooze, bulk actions - alerts/alert-states-and-fields-reference.md: episode states and field reference - alerts/query-alerts-and-signals-in-discover.md: ES|QL query guide Incorporates additions from PR #6395. Cross-references to pages in other PRs are commented out with TODO notes. Co-Authored-By: Claude Sonnet 4.6 --- .../kibana-alerting-experimental/alerts.md | 155 ++++++++++++++++++ .../alert-states-and-fields-reference.md | 58 +++++++ .../query-alerts-and-signals-in-discover.md | 29 ++++ .../alerts/view-and-manage-alerts.md | 134 +++++++++++++++ explore-analyze/toc.yml | 5 + 5 files changed, 381 insertions(+) create mode 100644 explore-analyze/alerting/kibana-alerting-experimental/alerts.md create mode 100644 explore-analyze/alerting/kibana-alerting-experimental/alerts/alert-states-and-fields-reference.md create mode 100644 explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md create mode 100644 explore-analyze/alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md diff --git a/explore-analyze/alerting/kibana-alerting-experimental/alerts.md b/explore-analyze/alerting/kibana-alerting-experimental/alerts.md new file mode 100644 index 0000000000..0ed5dbc588 --- /dev/null +++ b/explore-analyze/alerting/kibana-alerting-experimental/alerts.md @@ -0,0 +1,155 @@ +--- +navigation_title: Alerts +applies_to: + stack: unavailable + serverless: preview +products: + - id: kibana +description: "Alert episodes in experimental alerting features: lifecycle states, series and episodes, signals versus alerts, and where to find them." +--- + +# experimental alerting features alerts + +When a rule fires repeatedly on the same problem, a flat list of events doesn't tell you when the issue started, whether it's still happening, or how long it's been going on. Alert episodes fill that gap. Each episode is a persistent record of one issue on one series, from first breach through recovery, with every evaluation appended to the same history. Nothing is overwritten. + + + +## Alert lifecycle [alert-lifecycle] + +Every alert episode moves through these states: + +``` +inactive → pending → active → recovering → inactive +``` + +| State | What it means | +| --- | --- | +| Inactive | Problem fully resolved. You get a recovery notification. | +| Pending | Errors detected, but the system is waiting to confirm it's a real problem before fully alerting. | +| Active | Problem confirmed and ongoing. This is when you get notified. | +| Recovering | Errors have stopped, but the system is waiting to confirm it's truly resolved. | + + +Activation and recovery thresholds control how many consecutive evaluations must agree, or how long the condition must persist, before transitioning. + +### Example: First breach opens, first clear closes + +A checkout-latency rule runs in Alert mode every 5 minutes. Latency breaches at 14:05 and clears at 14:50: + +1. **14:00** — Routine check. p95 is within budget. The episode is `inactive`. +2. **14:05** — p95 jumps to 3.1s. The first breach is detected. With no activation threshold, the episode opens immediately as `active`. +3. **14:10–14:45** — Every evaluation finds high latency. The same episode stays `active`. No new episodes are created. +4. **14:50** — p95 drops back under 2s. With no recovery threshold, the episode resolves immediately to `inactive`. + +One problem is tracked in one episode, even though the rule evaluated many times while the condition was ongoing. + + + +### Example: Waiting for confirmation before opening and closing + +The same checkout-latency rule, now with an activation threshold of 2 consecutive breaches and a recovery threshold of 2 consecutive clears: + +1. **14:00** — Routine check. p95 is within budget. The episode is `inactive`. +2. **14:05** — p95 jumps to 3.1s. The first breach is detected. The episode is created in `pending` and the system starts counting consecutive breaches. +3. **14:10** — p95 is still elevated. The second consecutive breach meets the activation threshold. The episode moves from `pending` to `active`, and the engineer is paged. +4. **14:10–14:45** — Latency stays elevated. The episode remains `active`. +5. **14:50** — p95 drops back under 2s. The first clean check moves the episode to `recovering`. The system starts counting consecutive clears. +6. **14:55** — A second consecutive clear meets the recovery threshold. The episode moves from `recovering` to `inactive`. + +Thresholds prevent brief spikes from opening episodes and transient dips from closing them prematurely. The episode waits in `pending` until the problem is confirmed, and waits in `recovering` until the resolution is confirmed. + + + +## Series + +A series is the ongoing relationship between a rule and one specific thing it monitors. + +Your rule monitors services. Each service it tracks has its own series, one for `checkout-service`, one for `payment-service`, and so on. A series exists for as long as that rule keeps monitoring that service. + +Think of it like a patient's medical file. The file exists as long as the patient is in the system. Individual health incidents come and go, but the file persists. + + + +### How series and episodes relate + +An episode lives inside a series. A series can contain many episodes over its lifetime, one for each time that service had a problem. + +``` +Series: checkout-service +│ +├── Episode 1: errors on April 10 (active → inactive) +├── Episode 2: errors on April 15 (active → inactive) +└── Episode 3: errors on April 18 (active right now) +``` + +The series is the container. Episodes are the individual problems that happened within it. When the series breaches again after recovering, a new episode starts. + +This means you can track "the checkout service was broken from 02:14 to 03:21" and "the payment service was broken at the same time" as separate episodes, even when both come from the same rule. + +:::{tip} +Snooze operates at the series level, not the episode level. If you snooze `checkout-service`, you're silencing all notifications from that series for the next X hours, regardless of how many new episodes start during that time. You're quieting a specific ongoing situation, not a single alert. +::: + +### A practical way to think about it + +| Concept | Analogy | +| --- | --- | +| Rule | A security camera watching the building | +| Series | The camera's feed for one specific door | +| Episode | A specific incident caught on that feed | +| Rule events | The individual video frames | + +The camera runs continuously (rule), always watching door 3 (series). One night someone breaks in. That's an episode. The frames captured during the break-in are the rule events. + +## Signals versus alerts + +Every time a rule finds a match, it writes a document to `.rule-events`. Whether that document is a signal or an alert depends on the rule's mode, and that choice determines whether the system only records what happened or actively tracks it through to resolution. + +A **signal** is a one-time observation. The system writes it and moves on, no lifecycle, no notifications, no follow-up. An **alert** participates in an episode. The system links it to every other document from the same problem, tracks the lifecycle states, and routes notifications through action policies. + +| Type | What it is | When it's created | +| --- | --- | --- | +| Signal | A point-in-time record that the query matched (`type: signal`). Stored in `.rule-events`. | Rules in Detect mode | +| Alert | A lifecycle-tracked episode with `type: alert` and `episode.*` fields. Stored in `.rule-events`. | Rules in Alert mode | + +A rule in Detect mode only writes signals. It never opens episodes, so action policies have nothing to match against. + +## Where alerts live + +Alert events are stored in `.rule-events`. Triage actions (acknowledge, snooze, resolve) are stored in `.alert-actions`. Both are queryable in Discover. + +Every time you take an action on an episode — acknowledging it, snoozing it, resolving it, editing its tags — {{kib}} writes a new document to `.alert-actions`. These documents are append-only and can be queried in Discover for auditing and metrics such as mean time to acknowledge (MTTA). For field definitions, refer to [Alert states and fields reference](alerts/alert-states-and-fields-reference.md#alert-states-reference). + + + +### Data stream storage and retention + +Both `.rule-events` and `.alert-actions` are data streams, append-only, time-series stores optimized for writes. On every rule evaluation, {{kib}} writes a **new document** to `.rule-events` rather than updating the previous one. Each document is a point-in-time snapshot. The `episode.status` field records the lifecycle state the episode was in at that exact evaluation. Nothing is overwritten. + +Because every evaluation produces its own document, you can reconstruct the full history of an episode by querying all documents that share the same `episode.id`. Refer to [Query alerts and signals in Discover](alerts/query-alerts-and-signals-in-discover.md#explore-alerts-discover) for example queries. + +Retention is managed automatically through ILM. Older backing indices move through storage tiers and are deleted when the retention window expires. You do not need to manually remove documents. {{kib}} manages versioning, retention, and lifecycle for both streams. Do not change their mappings or index settings. + +## Related pages + +- **[View and manage alerts](alerts/view-and-manage-alerts.md):** Open the alert episodes table, triage active episodes, and acknowledge, snooze, or resolve them. +- **[Query alerts and signals in Discover](alerts/query-alerts-and-signals-in-discover.md):** Use {{esql}} to query `.rule-events` and `.alert-actions` for ad hoc analysis and dashboards. +- **[Alert states and fields reference](alerts/alert-states-and-fields-reference.md):** Look up lifecycle states, field names, and episode document structure. + diff --git a/explore-analyze/alerting/kibana-alerting-experimental/alerts/alert-states-and-fields-reference.md b/explore-analyze/alerting/kibana-alerting-experimental/alerts/alert-states-and-fields-reference.md new file mode 100644 index 0000000000..2c459c99bd --- /dev/null +++ b/explore-analyze/alerting/kibana-alerting-experimental/alerts/alert-states-and-fields-reference.md @@ -0,0 +1,58 @@ +--- +navigation_title: Alert states and fields +applies_to: + stack: unavailable + serverless: preview +products: + - id: kibana +description: "Reference for episode status, `.rule-events` row status, and `.alert-actions` document fields in the experimental alerting features." +--- + +# Alert states and fields reference [alert-states-reference] + + +Alert states and fields are part of the experimental alerting features in Kibana. Use these tables when you read alert UI state, query `.rule-events` or `.alert-actions` in Discover, or align API payloads with what operators see. For triage controls (acknowledge, snooze, resolve, tags) and how they map to storage, refer to [Alert actions](view-and-manage-alerts.md#alert-actions). + + +## Episode status + +The `episode.status` field appears on documents with `type: alert` in `.rule-events`. It represents the current lifecycle state of the alert episode. + +| Value | Description | +|---|---| +| `inactive` | Episode not in an active breach state in the lifecycle model. | +| `pending` | Condition met but activation thresholds not yet satisfied. | +| `active` | Episode is actively breaching per rule logic. | +| `recovering` | Condition clearing but recovery thresholds not yet satisfied. | + + + +## Rule event status + +The `status` field appears on all documents in `.rule-events`, for both `type: signal` and `type: alert`. It reflects the outcome of a single rule evaluation row, independent of the episode lifecycle. + +| Value | Description | +|---|---| +| `breached` | Condition met for this evaluation row. | +| `recovered` | Recovery path satisfied for this evaluation row. | +| `no_data` | No-data handling produced a no-data style outcome for this evaluation. | + +## Alert action document fields + +When a user or the system records an action on an alert episode, {{kib}} writes a document to `.alert-actions`. Use this stream for triage history, operational metrics such as mean time to acknowledge (MTTA), and auditing. It does not store what your rule query returned on each run — that output is in `.rule-events`. + +| Field | Type | Description | +|---|---|---| +| `@timestamp` | date | When the action was recorded. | +| `episode.id` | keyword | Target episode. | +| `rule.id` | keyword | Rule that owns the episode. | +| `action.type` | keyword | The action type, for example:
- `acknowledge`: User acknowledged the alert.
- `snooze`: Notifications snoozed for a period.
- `tag`: Tag applied to the alert.
- `fire`: Notification or escalation fired for the episode.
- `unmatched`: No action policy matched the episode, so no workflow ran for it under these policies.

For the full set of action types and UI behavior, refer to [Alert actions](view-and-manage-alerts.md#alert-actions). | +| `episode.status_count` | long | Count of consecutive evaluations in the current `episode.status`. Only set when `episode.status` is `pending` or `recovering`.
For example, if the episode stays `pending` for three rule evaluations in a row, the value is `3`. | diff --git a/explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md b/explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md new file mode 100644 index 0000000000..a6d7ca11d0 --- /dev/null +++ b/explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md @@ -0,0 +1,29 @@ +--- +navigation_title: Query alerts in Discover +applies_to: + stack: unavailable + serverless: preview +products: + - id: kibana +description: "Use {{esql}} in Discover against `.rule-events` and `.alert-actions`: sample queries, trends, and MTTA-style analysis for the experimental alerting features." +--- + +# Query alerts and signals in Discover [explore-alerts-discover] + + +Querying alerts and signals in Discover is part of the experimental alerting features in Kibana. Discover gives you direct {{esql}} access to everything the experimental alerting features record, including rule evaluation history, episode progressions, triage actions, and operational metrics like mean time to acknowledge. + +The Alerts UI shows current episode state. Discover lets you go further: ask arbitrary questions, spot trends over time, replay how a specific incident unfolded, or correlate alert history with other data in your environment. + +To use this page, open Discover, select {{esql}}, paste a query from the examples below, then adjust the time range and placeholders (`YOUR_RULE_ID`, `YOUR_GROUP_HASH`) to match your environment. + + + +For field names, types, and episode fields, refer to [Alert states and fields reference](alert-states-and-fields-reference.md#alert-states-reference). For triage in the product UI, refer to [View, manage, and reference alerts](view-and-manage-alerts.md). + + diff --git a/explore-analyze/alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md b/explore-analyze/alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md new file mode 100644 index 0000000000..f3fae94ed5 --- /dev/null +++ b/explore-analyze/alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md @@ -0,0 +1,134 @@ +--- +navigation_title: View and manage alerts +applies_to: + stack: unavailable + serverless: preview +products: + - id: kibana +description: "Open the experimental alerting features alert episodes table, triage actions, and episode details. Field and state tables live on a separate reference page." +--- + +# View and manage alerts [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. + + + +## Filter and search + +- **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. + +## Episode actions + +From any row in the table you can take the following row-level actions: + +- **Acknowledge / Unacknowledge:** Applies to the individual episode. +- **Snooze / Unsnooze:** Applies to the series (`group_hash`), so all rows in that series are affected. +- **Resolve / Unresolve:** Applies to the series. The episode shows as inactive in the UI when resolved, even if the underlying lifecycle data has not yet caught up. +- **Activate:** Manually moves the episode to `active` state. Use when the episode is in `pending` and you want to confirm the problem and start the notification flow without waiting for the activation threshold to be met. +- **Edit tags:** Opens a flyout where you can add new tags to the episode or remove existing ones. Tag changes apply to the individual episode and are persisted as `tag` actions in `.alert-actions`. Tags added this way appear in the **Tags** filter on the alerts table and can be queried in Discover for reporting and triage workflows. + +The same actions are available from the episode detail page. To assign an episode to a specific user, open the episode detail page. + +### Bulk actions [bulk-actions] + + +Select one or more rows using the checkboxes in the table to apply an action to multiple episodes at once. The same actions available at the row level (acknowledge, unacknowledge, snooze, unsnooze, resolve, activate, and edit tags) can be applied in bulk. + +Bulk actions follow the same scope rules as row-level actions: acknowledge and activate apply per episode, while snooze and resolve apply per group. When you snooze a selection of episodes that belong to different groups, each group is snoozed independently for the duration you set. + +### Snooze an episode [snooze-episode] + + +Snoozing suppresses notifications for an alert series for a defined period. The rule continues to evaluate during the snooze window and the episode stays visible in the alerts table, but no notifications are sent until the snooze expires. + +To snooze a single episode, select **Snooze** on any row. A quick-snooze popover opens with preset duration options so you can silence the episode in one click. Snooze applies at the group level. All episodes sharing the same `group_hash` are silenced for the duration, not just the row you acted on. The snooze expires automatically when the duration ends. + +Use snooze when a known condition is expected to persist for a fixed time and you want to stop the noise without disabling the rule entirely. For example, during a scheduled maintenance window or a known noisy period for a specific host. + +### Unsnooze an episode [unsnooze-episode] + + +To end a snooze early for a single episode, select **Unsnooze** on the row. Because snooze applies at the group level, unsnoozing one row clears the snooze for all episodes in the same group. Every episode sharing the same `group_hash` starts receiving notifications again immediately. + +To unsnooze multiple episodes at once, select rows using the checkboxes and choose **Unsnooze** from the bulk actions menu. Bulk unsnooze follows the same group-level scope, where each selected episode's entire group is cleared. + +## Open in Discover [open-episode-in-discover] + + +Select **Discover** on a row to open the rule's base query in Discover. The base query is the {{esql}} statement the rule runs on each evaluation. It reflects the data the alert is monitoring, not just the specific rows that breached the condition. Discover opens scoped to a time window around the episode so you can see the underlying data in context. +Snooze applies at the series level. All episodes sharing the same `group_hash` are silenced for the duration, not just the row you acted on. Use snooze when a known condition is expected to persist for a fixed time and you want to stop the noise without disabling the rule entirely. The snooze expires automatically when the duration ends. + +Use this when you want to understand why an episode opened, verify that the rule is querying the data you expect, or investigate whether a condition is genuinely a problem or an artifact of the data shape. + + + +For ad hoc analysis over `.rule-events` and `.alert-actions` with copy-paste {{esql}} examples, refer to [Query alerts and signals in Discover](query-alerts-and-signals-in-discover.md). + +## Episode detail page [alert-episode-details] + + +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. +- **Assignee:** The user currently responsible for the episode. Only one user can be assigned at a time. +- **Related episodes:** Other episodes on the same rule or series, split into two subsections for easier triage. +- **Actors:** Users who have taken actions on the episode, visible so teams can track activity and accountability. +- **Metadata:** A dedicated tab surfacing additional fields from the source event that triggered the alert. +- **Grouping:** When the rule uses grouping, the detail view surfaces the field values that identify the series. + +### Related episodes [related-episodes] + + +The **Related episodes** section is split into two subsections that help you distinguish between a condition that keeps recurring on one entity and a rule that is triggering across many different entities: + +- **Same alert series:** Other episodes sharing the same `rule_id` and `group_hash` as the current episode. These represent recurrences of the exact same alert condition — the same rule firing on the same series (for example, the same host or service). If this list is long, the condition is repeating and the underlying issue may not be fully resolved each time. +- **Other series for this rule:** Episodes from the same rule but with a different `group_hash`, or all other rule episodes when the rule does not use grouping. These show broader rule activity — other entities or conditions the same rule is also triggering on. Use this list to understand the rule's overall blast radius and whether a problem is isolated to one entity or affecting many. + +### Metadata tab [metadata-tab] + + +The **Metadata** tab surfaces additional information about the alert episode that is not shown in the main detail view. This includes field values from the source event that triggered the alert, giving you direct access to the raw signal during triage without switching to Discover. + +Use the **Metadata** tab when you need to inspect specific field values that are embedded in the alert's source data but not surfaced in the lifecycle or grouping sections. For example, use the tab to identify a rule's resources or version. + +### Actors [actors] + + +The **Actors** section lists the users who have taken actions on the episode (who acknowledged it, who snoozed it, and who resolved it) and when each action was taken. This gives teams visibility into the response history for an episode, which is useful for accountability and coordination. + +### Assign an episode [assign-episode] + + +From the episode detail page, you can assign the episode to a specific user to indicate who is responsible for investigating or resolving it. Only one user can be assigned at a time — assigning replaces any existing assignee. To remove an assignment without replacing it, clear the assigned user. + +Use assignment when your team needs clear ownership during triage. When multiple people are working through the alerts table at the same time, assigning an episode signals that someone has taken responsibility for it, which prevents duplicate work and makes it easier to track who is handling which issues. + +## Action scope reference [alert-actions] + + +### Episode scope versus series scope + +Some actions apply only to the specific episode you acted on. Others apply to every episode in the same series, meaning all episodes that share the same rule and `group_hash`. This matters when a rule tracks multiple services or hosts. Snoozing one episode silences the whole series, not only that service. + +| Action | Scope | +|---|---| +| Acknowledge / Unacknowledge | Episode | +| Activate | Episode | +| Snooze / Unsnooze | Group | +| Resolve / Unresolve | Group | +| Edit tags | Episode | +| Assign | Episode | + +For field definitions and state descriptions, refer to [Alert states and fields reference](alert-states-and-fields-reference.md#alert-states-reference). + diff --git a/explore-analyze/toc.yml b/explore-analyze/toc.yml index 2a57f93a92..d14957bbb8 100644 --- a/explore-analyze/toc.yml +++ b/explore-analyze/toc.yml @@ -380,6 +380,11 @@ toc: - file: report-and-share/reporting-troubleshooting-pdf.md - file: alerting.md children: + - file: alerting/kibana-alerting-experimental/alerts.md + children: + - file: alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md + - file: alerting/kibana-alerting-experimental/alerts/alert-states-and-fields-reference.md + - file: alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md - file: alerting/alerts.md children: - file: alerting/alerts/alerting-getting-started.md From f9606e3d8e7e52574372aeb887dbe81c663a8b65 Mon Sep 17 00:00:00 2001 From: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> Date: Fri, 15 May 2026 16:49:53 -0400 Subject: [PATCH 2/2] Apply suggestions from code review Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> --- .../alerting/kibana-alerting-experimental/alerts.md | 4 ++++ .../alerts/query-alerts-and-signals-in-discover.md | 2 ++ .../alerts/view-and-manage-alerts.md | 2 ++ 3 files changed, 8 insertions(+) diff --git a/explore-analyze/alerting/kibana-alerting-experimental/alerts.md b/explore-analyze/alerting/kibana-alerting-experimental/alerts.md index 0ed5dbc588..9f9882146f 100644 --- a/explore-analyze/alerting/kibana-alerting-experimental/alerts.md +++ b/explore-analyze/alerting/kibana-alerting-experimental/alerts.md @@ -131,7 +131,9 @@ A rule in Detect mode only writes signals. It never opens episodes, so action po Alert events are stored in `.rule-events`. Triage actions (acknowledge, snooze, resolve) are stored in `.alert-actions`. Both are queryable in Discover. + @@ -140,7 +142,9 @@ Every time you take an action on an episode — acknowledging it, snoozing it, r Both `.rule-events` and `.alert-actions` are data streams, append-only, time-series stores optimized for writes. On every rule evaluation, {{kib}} writes a **new document** to `.rule-events` rather than updating the previous one. Each document is a point-in-time snapshot. The `episode.status` field records the lifecycle state the episode was in at that exact evaluation. Nothing is overwritten. + Retention is managed automatically through ILM. Older backing indices move through storage tiers and are deleted when the retention window expires. You do not need to manually remove documents. {{kib}} manages versioning, retention, and lifecycle for both streams. Do not change their mappings or index settings. diff --git a/explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md b/explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md index a6d7ca11d0..de710d778c 100644 --- a/explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md +++ b/explore-analyze/alerting/kibana-alerting-experimental/alerts/query-alerts-and-signals-in-discover.md @@ -22,7 +22,9 @@ To use this page, open Discover, select {{esql}}, paste a query from the example + diff --git a/explore-analyze/alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md b/explore-analyze/alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md index f3fae94ed5..e28c135aad 100644 --- a/explore-analyze/alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md +++ b/explore-analyze/alerting/kibana-alerting-experimental/alerts/view-and-manage-alerts.md @@ -128,7 +128,9 @@ Some actions apply only to the specific episode you acted on. Others apply to ev | Edit tags | Episode | | Assign | Episode | +