From faaad5845e5ac0b92fc2ab9e5918f17b70b3334b Mon Sep 17 00:00:00 2001 From: Florent Le Borgne Date: Wed, 26 Nov 2025 14:53:49 +0100 Subject: [PATCH 1/2] Alerts and cases 20 first lines optimiation --- .gitignore | 2 +- explore-analyze/alerts-cases.md | 23 ++++++++++--------- explore-analyze/alerts-cases/alerts.md | 5 +++- .../alerts/alerting-common-issues.md | 5 ++-- .../alerts/alerting-getting-started.md | 5 +++- .../alerts-cases/alerts/alerting-setup.md | 5 ++-- .../alerts/alerting-troubleshooting.md | 5 ++-- .../alerts/create-manage-rules.md | 5 ++-- .../alerts-cases/alerts/event-log-index.md | 1 + .../alerts-cases/alerts/geo-alerting.md | 5 ++-- .../alerts/maintenance-windows.md | 5 ++-- .../alerts/notifications-domain-allowlist.md | 3 ++- .../alerts/rule-action-variables.md | 3 ++- .../alerts-cases/alerts/rule-type-es-query.md | 5 ++-- .../alerts/rule-type-index-threshold.md | 5 ++-- .../alerts-cases/alerts/rule-types.md | 3 ++- .../alerts-cases/alerts/testing-connectors.md | 3 ++- .../alerts-cases/alerts/view-alerts.md | 5 ++-- explore-analyze/alerts-cases/cases.md | 3 ++- .../alerts-cases/cases/cases-as-data.md | 5 +++- .../cases/manage-cases-settings.md | 5 ++-- .../alerts-cases/cases/manage-cases.md | 5 ++-- .../alerts-cases/cases/setup-cases.md | 5 ++-- explore-analyze/alerts-cases/watcher.md | 21 +++++++++-------- .../alerts-cases/watcher/action-conditions.md | 3 ++- .../alerts-cases/watcher/action-foreach.md | 3 ++- .../alerts-cases/watcher/actions-email.md | 3 ++- .../alerts-cases/watcher/actions-index.md | 3 ++- .../alerts-cases/watcher/actions-jira.md | 3 ++- .../alerts-cases/watcher/actions-logging.md | 5 ++-- .../alerts-cases/watcher/actions-pagerduty.md | 3 ++- .../alerts-cases/watcher/actions-slack.md | 3 ++- .../alerts-cases/watcher/actions-webhook.md | 3 ++- .../alerts-cases/watcher/actions.md | 5 ++-- .../alerts-cases/watcher/condition-always.md | 3 ++- .../watcher/condition-array-compare.md | 3 ++- .../alerts-cases/watcher/condition-compare.md | 3 ++- .../alerts-cases/watcher/condition-never.md | 3 ++- .../alerts-cases/watcher/condition-script.md | 3 ++- .../alerts-cases/watcher/condition.md | 5 ++-- .../alerts-cases/watcher/enable-watcher.md | 3 ++- .../alerts-cases/watcher/encrypting-data.md | 5 ++-- .../alerts-cases/watcher/example-watches.md | 3 ++- .../alerts-cases/watcher/execute-watch.md | 3 ++- .../alerts-cases/watcher/how-watcher-works.md | 7 +++--- .../alerts-cases/watcher/input-chain.md | 3 ++- .../alerts-cases/watcher/input-http.md | 3 ++- .../alerts-cases/watcher/input-search.md | 3 ++- .../alerts-cases/watcher/input-simple.md | 3 ++- explore-analyze/alerts-cases/watcher/input.md | 5 ++-- .../alerts-cases/watcher/managing-watches.md | 3 ++- .../alerts-cases/watcher/schedule-types.md | 5 ++-- .../alerts-cases/watcher/throttling.md | 3 ++- .../alerts-cases/watcher/transform-chain.md | 3 ++- .../alerts-cases/watcher/transform-script.md | 3 ++- .../alerts-cases/watcher/transform-search.md | 3 ++- .../alerts-cases/watcher/transform.md | 5 ++-- .../alerts-cases/watcher/trigger-schedule.md | 3 ++- .../alerts-cases/watcher/trigger.md | 5 ++-- .../watcher/watch-cluster-status.md | 5 ++-- .../watcher/watcher-getting-started.md | 5 ++-- .../watcher/watcher-limitations.md | 3 ++- .../alerts-cases/watcher/watcher-ui.md | 7 ++++-- 63 files changed, 175 insertions(+), 107 deletions(-) diff --git a/.gitignore b/.gitignore index 102aa91b50..15f139c8e1 100644 --- a/.gitignore +++ b/.gitignore @@ -9,7 +9,7 @@ # Add LLM/AI related files AGENTS.md .github/copilot-instructions.md -.github/instructions/**.instructions.md +.github/instructions CLAUDE.md GEMINI.md .cursor diff --git a/explore-analyze/alerts-cases.md b/explore-analyze/alerts-cases.md index 805c131402..c7de70b4f0 100644 --- a/explore-analyze/alerts-cases.md +++ b/explore-analyze/alerts-cases.md @@ -8,36 +8,37 @@ applies_to: products: - id: kibana - id: cloud-serverless +description: Overview of alerting and case management tools for monitoring data and managing incident response. --- -# Alerts and cases +# Alerts and cases [alerts-cases] -Alerting tools in Elasticsearch and Kibana provide functionality to monitor data and notify you about significant changes or events in real time. This page provides an overview of how the key components work. +Alerting and case management in {{product.elasticsearch}} and {{product.kibana}} enable you to monitor data continuously, receive real-time notifications when specific conditions are met, and track incident investigations collaboratively. These tools help you detect issues early, respond quickly, and maintain visibility throughout the resolution process. -## Alerts +## Alerts [alerts-overview] -Alerts are notifications generated when specific conditions are met. These notifications are sent to you through channels that you previously set such as email, Slack, webhooks, PagerDuty, and so on. Alerts are created based on rules, which define the criteria for triggering them. Rules monitor the data indexed in Elasticsearch and evaluate conditions on a defined schedule to identify matches. For example, a threshold rule can generate an alert when a value crosses a specific threshold, while a machine learning rule activates an alert when an anomaly detection job identifies an anomaly. +Alerts are notifications generated when specific conditions are met. These notifications are sent to you through channels that you previously set such as email, Slack, webhooks, PagerDuty, and so on. Alerts are created based on rules, which define the criteria for triggering them. {{rules-ui}} monitor the data indexed in {{product.elasticsearch}} and evaluate conditions on a defined schedule to identify matches. For example, a threshold rule can generate an alert when a value crosses a specific threshold, while a {{ml}} rule activates an alert when an {{anomaly-job}} identifies an anomaly. -## Cases +## Cases [cases-overview] Cases are a collaboration and tracking tool, which is particularly useful for incidents or issues that arise from alerts. You can group related alerts into a case for easier management, add notes and comments to provide context, track investigation progress, and assign cases to team members or link them to external systems. Cases ensure that teams have a central place to track and resolve alerts efficiently. -## Maintenance windows +## {{maint-windows-cap}} [maintenance-windows-overview] -If you have a planned outage, maintenance windows prevent rules from generating notifications in that period. Alerts still occur but their notifications are suppressed. +If you have a planned outage, {{maint-windows}} prevent rules from generating notifications in that period. Alerts still occur but their notifications are suppressed. -### Workflow Example +### Workflow example [workflow-example] 1. **Rule Creation**: You set up a rule to monitor server logs for failed login attempts exceeding 5 within a 10-minute window. 1. **Alert Generation**: When the rule's condition is met, an alert is created. 1. **Notification**: The alert runs an action, such as sending a Slack message or an email, unless a maintenance window is active. 1. **Case Management**: If the alert is part of an ongoing investigation, it's added to a case for further analysis and resolution. -By combining these tools, Elasticsearch and Kibana enable incident response workflows, helping teams to detect, investigate, and resolve issues efficiently. +By combining these tools, {{product.elasticsearch}} and {{product.kibana}} enable incident response workflows, helping teams to detect, investigate, and resolve issues efficiently. -## Watcher +## {{watcher}} [watcher-overview] ```{applies_to} serverless: unavailable ``` -You can use Watcher for alerting and monitoring specific conditions in your data. It enables you to define rules and take automated actions when certain criteria are met. Watcher is a powerful alerting tool for custom use cases and more complex alerting logic. It allows advanced scripting using Painless to define complex conditions and transformations. +You can use {{watcher}} for alerting and monitoring specific conditions in your data. It enables you to define rules and take automated actions when certain criteria are met. {{watcher}} is a powerful alerting tool for custom use cases and more complex alerting logic. It allows advanced scripting using {{product.painless}} to define complex conditions and transformations. diff --git a/explore-analyze/alerts-cases/alerts.md b/explore-analyze/alerts-cases/alerts.md index 9c5ce6f123..28d5331def 100644 --- a/explore-analyze/alerts-cases/alerts.md +++ b/explore-analyze/alerts-cases/alerts.md @@ -10,9 +10,12 @@ products: - id: kibana - id: cloud-serverless - id: cloud-hosted +description: Overview of alerts and rules for monitoring data and sending notifications when conditions are met. --- -# Alerts +# Alerts [alerts] + +Alerts enable you to monitor your data continuously and receive notifications when specific conditions are met. Using rules, you define what to detect, how often to check, and what actions to take—such as sending emails, creating Slack messages, or triggering webhooks. This proactive monitoring helps you identify and respond to issues quickly, whether you're tracking infrastructure health, security events, or business metrics. ## {{rules-app}} [rules] diff --git a/explore-analyze/alerts-cases/alerts/alerting-common-issues.md b/explore-analyze/alerts-cases/alerts/alerting-common-issues.md index 95abc28c8c..6dcd95883f 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-common-issues.md +++ b/explore-analyze/alerts-cases/alerts/alerting-common-issues.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Troubleshooting guide for resolving common alerting issues including rule timing and execution problems. --- -# Common issues with {{kib}} alerting [alerting-common-issues] +# Common alerting issues [alerting-common-issues] -This page describes how to resolve common problems you might encounter with Alerting. +This page describes how to identify and resolve common problems you might encounter with alerting, including rules running late, inconsistent cadence, excessive executions, and action failures. ## Rules with small check intervals run late [rules-small-check-interval-run-late] diff --git a/explore-analyze/alerts-cases/alerts/alerting-getting-started.md b/explore-analyze/alerts-cases/alerts/alerting-getting-started.md index 883c3261b5..e452e8b910 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-getting-started.md +++ b/explore-analyze/alerts-cases/alerts/alerting-getting-started.md @@ -3,11 +3,14 @@ applies_to: stack: ga serverless: ga navigation_title: Getting started with alerts +products: + - id: kibana +description: Step-by-step tutorial for creating and configuring your first alerting rule. --- # Getting started with alerting [alerting-getting-started] -Alerting enables you to define *rules*, which detect complex conditions within different {{kib}} apps and trigger actions when those conditions are met. Alerting is integrated with [**{{observability}}**](../../../solutions/observability/incident-management/alerting.md), [**Security**](detection-rules://index.md), [**Maps**](../../../explore-analyze/alerts-cases/alerts/geo-alerting.md) and [**{{ml-app}}**](../../../explore-analyze/machine-learning/anomaly-detection/ml-configuring-alerts.md). It can be centrally managed from **{{stack-manage-app}}** and provides a set of built-in [connectors](../../../deploy-manage/manage-connectors.md) and [rules](../../../explore-analyze/alerts-cases/alerts/rule-types.md#stack-rules) for you to use. +Alerting enables you to define rules that detect complex conditions within different {{kib}} apps and trigger actions when those conditions are met. Alerting is integrated with {{observability}}, **Security**, **Maps**, and the **{{ml-app}}**, can be centrally managed from **{{stack-manage-app}}**, and provides a set of built-in connectors and rules for you to use. :::{image} /explore-analyze/images/kibana-alerting-overview.png :alt: {{rules-ui}} UI diff --git a/explore-analyze/alerts-cases/alerts/alerting-setup.md b/explore-analyze/alerts-cases/alerts/alerting-setup.md index ee8e33dc5d..5258613ed0 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-setup.md +++ b/explore-analyze/alerts-cases/alerts/alerting-setup.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Configuration instructions for setting up alerting, including prerequisites and production considerations. --- -# Set up [alerting-setup] +# Set up alerting [alerting-setup] -{{kib}} {{alert-features}} are automatically enabled, but might require some additional configuration. +{{kib}} {{alert-features}} are automatically enabled but might require additional configuration for encryption keys, email settings, and production deployments. This page covers prerequisites, required settings, and production considerations for running alerting at scale. ## Prerequisites [alerting-prerequisites] diff --git a/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md b/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md index d626709e50..48c5fc903a 100644 --- a/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md +++ b/explore-analyze/alerts-cases/alerts/alerting-troubleshooting.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Troubleshooting guide for diagnosing and resolving issues with alerting rules and connectors. --- -# Troubleshooting and limitations of alerting in {{kib}} [alerting-troubleshooting] +# Troubleshooting and limitations of alerting [alerting-troubleshooting] -Alerting provides many options for diagnosing problems with rules and connectors. +When issues occur with alerting rules or connectors, {{kib}} provides several diagnostic tools and logging capabilities to help identify and resolve problems. This page covers debugging tools, log analysis, and known limitations of the alerting framework. ## Check the {{kib}} log [alerting-kibana-log] diff --git a/explore-analyze/alerts-cases/alerts/create-manage-rules.md b/explore-analyze/alerts-cases/alerts/create-manage-rules.md index d55a94a686..ac137dd610 100644 --- a/explore-analyze/alerts-cases/alerts/create-manage-rules.md +++ b/explore-analyze/alerts-cases/alerts/create-manage-rules.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Instructions for creating, editing, and managing alerting rules in Kibana. --- -# Create and manage alerting rules with {{kib}} [create-and-manage-rules] +# Create and manage alerting rules [create-and-manage-rules] -The **{{stack-manage-app}}** > **{{rules-ui}}** UI provides a cross-app view of alerting. Different {{kib}} apps like [**{{observability}}**](../../../solutions/observability/incident-management/alerting.md), [**Security**](detection-rules://index.md), [**Maps**](geo-alerting.md) and [**{{ml-app}}**](../../machine-learning/machine-learning-in-kibana.md) can offer their own rules. +The **{{stack-manage-app}}** > **{{rules-ui}}** UI provides a cross-app view of alerting where you can create, edit, enable, disable, mute, and delete rules. Different {{kib}} apps like {{observability}}, **Security**, **Maps**, and the **{{ml-app}}** can offer their own rules, all manageable from this central location. You can find **Rules** in **Stack Management** > **Alerts and insights** > **Rules** in {{kib}} or by using the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). diff --git a/explore-analyze/alerts-cases/alerts/event-log-index.md b/explore-analyze/alerts-cases/alerts/event-log-index.md index 27a1ca3017..0d6edded9f 100644 --- a/explore-analyze/alerts-cases/alerts/event-log-index.md +++ b/explore-analyze/alerts-cases/alerts/event-log-index.md @@ -6,6 +6,7 @@ applies_to: serverless: ga products: - id: kibana +description: Reference for querying the event log index to diagnose rule execution and action performance. --- # Event log index [event-log-index] diff --git a/explore-analyze/alerts-cases/alerts/geo-alerting.md b/explore-analyze/alerts-cases/alerts/geo-alerting.md index 51b580363b..efa57478ac 100644 --- a/explore-analyze/alerts-cases/alerts/geo-alerting.md +++ b/explore-analyze/alerts-cases/alerts/geo-alerting.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Reference for the Tracking containment rule type for geospatial alerting on entity movements. --- -# Tracking containment [geo-alerting] +# Tracking containment rule [geo-alerting] -The tracking containment rule alerts when an entity is contained or no longer contained within a boundary. +The **Tracking containment** rule type monitors entity movements and triggers alerts when an entity enters or exits a defined geographical boundary. This rule type is useful for tracking assets, monitoring restricted zones, or detecting location-based events. In **{{stack-manage-app}}** > **{{rules-ui}}**, click **Create rule**. Select the **Tracking containment** rule type then fill in the name and optional tags. diff --git a/explore-analyze/alerts-cases/alerts/maintenance-windows.md b/explore-analyze/alerts-cases/alerts/maintenance-windows.md index 9e3215c792..2c61d330f4 100644 --- a/explore-analyze/alerts-cases/alerts/maintenance-windows.md +++ b/explore-analyze/alerts-cases/alerts/maintenance-windows.md @@ -8,14 +8,15 @@ applies_to: products: - id: kibana - id: cloud-serverless +description: Instructions for scheduling maintenance windows to suppress rule notifications during planned outages. --- -# Maintenance windows +# {{maint-windows-cap}} [maintenance-windows] This content applies to: [![Observability](/explore-analyze/images/serverless-obs-badge.svg "")](../../../solutions/observability.md) [![Security](/explore-analyze/images/serverless-sec-badge.svg "")](../../../solutions/security.md) -You can schedule single or recurring maintenance windows to temporarily reduce rule notifications. For example, a maintenance window prevents false alarms during planned outages. +You can schedule single or recurring {{maint-windows}} to temporarily suppress rule notifications during planned outages or maintenance periods. Alerts continue to be generated, but notifications are suppressed according to the maintenance window schedule. By default, a maintenance window affects all rules in all {{kib}} apps within its space. You can refine the scope of a maintenance window by adding filters and rule categories. diff --git a/explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md b/explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md index 5da3269707..a9c4aadd98 100644 --- a/explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md +++ b/explore-analyze/alerts-cases/alerts/notifications-domain-allowlist.md @@ -6,11 +6,12 @@ applies_to: serverless: ga products: - id: cloud-hosted +description: Instructions for configuring the domain allowlist that restricts email recipients for alerting notifications. --- # Notifications domain allowlist [organizations-notifications-domain-allowlist] -The notifications domain allowlist restricts the possible recipients for alert emails. {{es}} Watcher and {{kib}} alerting actions send emails only if the recipient domains are included in this allowlist. +The notifications domain allowlist restricts the possible recipients for alert emails. {{es}} {{watcher}} and {{kib}} alerting actions send emails only if the recipient domains are included in this allowlist. You can configure the allowlist from your organization's Contacts page. ::::{note} The recipients are only restricted if one or more domains are configured. If there are no domains configured, notifications can be sent to any recipient domain (No restrictions apply). diff --git a/explore-analyze/alerts-cases/alerts/rule-action-variables.md b/explore-analyze/alerts-cases/alerts/rule-action-variables.md index 84b77c8055..d2c4d6ae7f 100644 --- a/explore-analyze/alerts-cases/alerts/rule-action-variables.md +++ b/explore-analyze/alerts-cases/alerts/rule-action-variables.md @@ -6,11 +6,12 @@ applies_to: serverless: ga products: - id: kibana +description: Reference for variables that can be used in rule actions using Mustache template syntax. --- # Rule action variables [rule-action-variables] -Alerting rules can use the [Mustache](https://mustache.github.io/mustache.5.html) template syntax (`{{variable name}}`) to pass values when the actions run. +Alerting rules can use [Mustache](https://mustache.github.io/mustache.5.html) template syntax (`{{variable name}}`) to pass dynamic values from the rule context to actions when they run. This enables you to include rule-specific details like alert names, threshold values, and matched documents in notifications. ## Common variables [common-rule-action-variables] diff --git a/explore-analyze/alerts-cases/alerts/rule-type-es-query.md b/explore-analyze/alerts-cases/alerts/rule-type-es-query.md index fcbb027972..c33a317806 100644 --- a/explore-analyze/alerts-cases/alerts/rule-type-es-query.md +++ b/explore-analyze/alerts-cases/alerts/rule-type-es-query.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Reference for the Elasticsearch query rule type, which runs queries and triggers actions based on match thresholds. --- -# Elasticsearch query [rule-type-es-query] +# {{es}} query rule [rule-type-es-query] -The {{es}} query rule type runs a user-configured query, compares the number of matches to a configured threshold, and schedules actions to run when the threshold condition is met. +The **{{es}} query** rule type runs a user-configured query, compares the number of matches to a configured threshold, and schedules actions to run when the threshold condition is met. This rule type supports multiple query languages: {{es}} Query Domain Specific Language (Query DSL), {{es}} Query Language ({{esql}}), {{kib}} Query Language (KQL), and Lucene. In **{{stack-manage-app}}** > **{{rules-ui}}**, click **Create rule**. Select the **{{es}} query** rule type then fill in the name and optional tags. An {{es}} query rule can be defined using {{es}} Query Domain Specific Language (DSL), {{es}} Query Language (ES|QL), {{kib}} Query Language (KQL), or Lucene. diff --git a/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md b/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md index 859be8e5ee..31514ef013 100644 --- a/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md +++ b/explore-analyze/alerts-cases/alerts/rule-type-index-threshold.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Reference for the Index threshold rule type, which aggregates field values and triggers actions when thresholds are met. --- -# Index threshold [rule-type-index-threshold] +# Index threshold rule [rule-type-index-threshold] -The index threshold rule type runs an {{es}} query. It aggregates field values from documents, compares them to threshold values, and schedules actions to run when the thresholds are met. +The **Index threshold** rule type runs an {{es}} query that aggregates field values from documents, compares them to threshold values, and schedules actions to run when the thresholds are met. This rule type is useful for monitoring metrics like average response times, document counts, or summed values that cross defined limits. In **{{stack-manage-app}}** > **{{rules-ui}}**, click **Create rule**. Select the **Index threshold** rule type then fill in the name and optional tags. diff --git a/explore-analyze/alerts-cases/alerts/rule-types.md b/explore-analyze/alerts-cases/alerts/rule-types.md index 23d3764326..a99b5fe070 100644 --- a/explore-analyze/alerts-cases/alerts/rule-types.md +++ b/explore-analyze/alerts-cases/alerts/rule-types.md @@ -6,11 +6,12 @@ applies_to: serverless: ga products: - id: kibana +description: Reference of available rule types for alerting in Kibana, including Stack rules and app-specific rules. --- # Rule types [rule-types] -A rule is a set of [conditions](../alerts.md#rules-conditions), [schedules](../alerts.md#rules-schedule), and [actions](../alerts.md#rules-actions ) that enable notifications. {{kib}} provides rules built into the {{stack}} and rules registered by one of the {{kib}} apps. You can create most rules types in [{{stack-manage-app}} > {{rules-ui}}](create-manage-rules.md). Security rules must be defined in the Security app. For more information, refer to the documentation about [creating a detection rule](../../../solutions/security/detect-and-alert/create-detection-rule.md). +Rule types define how conditions are detected and what actions are triggered when those conditions are met. {{kib}} provides Stack rules built into the {{stack}} and app-specific rules registered by {{kib}} apps. You can create most rule types in **{{stack-manage-app}}** > **{{rules-ui}}**, though Security rules must be created in the **Security** app. ::::{note} Some rule types are subscription features, while others are free features. For a comparison of the Elastic subscription levels, see [the subscription page](https://www.elastic.co/subscriptions). diff --git a/explore-analyze/alerts-cases/alerts/testing-connectors.md b/explore-analyze/alerts-cases/alerts/testing-connectors.md index 12d512c6a3..0a10e3e07d 100644 --- a/explore-analyze/alerts-cases/alerts/testing-connectors.md +++ b/explore-analyze/alerts-cases/alerts/testing-connectors.md @@ -6,11 +6,12 @@ applies_to: serverless: ga products: - id: kibana +description: Instructions for testing connectors to verify they work correctly before using them in rules. --- # Test connectors [testing-connectors] -In **{{stack-manage-app}} > {{connectors-ui}}**, you can test a newly created connector by navigating to the Test tab of Connector Edit flyout or by clicking "Save & test" button on Create flyout: +You can test connectors to verify they work correctly before using them in rules. In **{{stack-manage-app}}** > **{{connectors-ui}}**, navigate to the **Test** tab of the connector edit flyout or click **Save & test** when creating a new connector: :::{image} /explore-analyze/images/kibana-connector-save-and-test.png :alt: Rule management page with the errors banner diff --git a/explore-analyze/alerts-cases/alerts/view-alerts.md b/explore-analyze/alerts-cases/alerts/view-alerts.md index 09e33160ce..f4c8f258ef 100644 --- a/explore-analyze/alerts-cases/alerts/view-alerts.md +++ b/explore-analyze/alerts-cases/alerts/view-alerts.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Instructions for viewing, filtering, and managing alerts in Kibana. --- -# View and manage alerts in {{kib}} [view-alerts] +# View and manage alerts [view-alerts] -When the conditions of a rule are met, it creates an alert. If the rule has actions, they run at the defined frequency. For example, the rule can send email notifications for each alert at a custom interval. For an introduction to the concepts of rules, alerts, and actions, refer to [Alerting](../alerts.md). +When a rule's conditions are met, it creates an alert. If the rule has actions configured, they run at the defined frequency—for example, sending email notifications for each alert at a custom interval. You can view and manage all alerts in **{{stack-manage-app}}** > **Alerts**, or view alerts specific to a rule from the **{{rules-ui}}** page. You can manage the alerts for each rule in **{{stack-manage-app}}** > **{{rules-ui}}**. Alternatively, manage all your alerts in **{{stack-manage-app}}** > **Alerts**. diff --git a/explore-analyze/alerts-cases/cases.md b/explore-analyze/alerts-cases/cases.md index 3ccf247bd6..06517fa23e 100644 --- a/explore-analyze/alerts-cases/cases.md +++ b/explore-analyze/alerts-cases/cases.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Overview of case management for tracking and collaborating on incidents and issues. --- # Cases in {{kib}} [cases] -Cases are used to open and track issues directly in {{kib}}. You can add assignees and tags to your cases, set their severity and status, and add alerts, comments, and visualizations. You can create cases automatically when alerts occur or send cases to external incident management systems by configuring connectors. +**Cases** provide a centralized workspace for tracking and collaborating on incidents and issues directly in {{kib}}. You can create cases manually or automatically from alerts, add assignees and tags, set severity and status, and attach alerts, comments, and visualizations. Cases integrate with external incident management systems through connectors, enabling seamless workflows for investigation and resolution. {applies_to}`stack: preview` {applies_to}`serverless: preview` You can also optionally add custom fields and case templates. diff --git a/explore-analyze/alerts-cases/cases/cases-as-data.md b/explore-analyze/alerts-cases/cases/cases-as-data.md index 9b692598bc..ad551b1bdb 100644 --- a/explore-analyze/alerts-cases/cases/cases-as-data.md +++ b/explore-analyze/alerts-cases/cases/cases-as-data.md @@ -2,11 +2,14 @@ applies_to: stack: preview 9.2 serverless: unavailable +products: + - id: kibana +description: Instructions for enabling and using the cases as data feature to visualize case metrics and trends. --- # Use cases as data [use-cases-as-data] -The cases as data feature lets you visualize data about cases in your [space](/deploy-manage/manage-spaces.md). After turning it on, you can query case data from dedicated case analytics indices and build dashboards and visualizations to track case trends and operational metrics. This information is particularly useful when reporting on key performance indicators (KPIs) such as Mean Time To Respond (MTTR), case severity trends, and analyst workload. +The cases as data feature enables you to visualize case data and build dashboards that track case trends and operational metrics. After turning it on, {{es}} automatically creates case analytics indices in each space with cases, which you can query to monitor key performance indicators (KPIs) such as Mean Time To Respond (MTTR), case severity trends, and analyst workload. ::::{admonition} Requirements To use cases as data, you must have the appropriate subscription. Refer to the subscription page for [Elastic Cloud](https://www.elastic.co/subscriptions/cloud) and [Elastic Stack/self-managed](https://www.elastic.co/subscriptions) for the breakdown of available features and their associated subscription tiers. diff --git a/explore-analyze/alerts-cases/cases/manage-cases-settings.md b/explore-analyze/alerts-cases/cases/manage-cases-settings.md index e3e09000b3..98dd92b737 100644 --- a/explore-analyze/alerts-cases/cases/manage-cases-settings.md +++ b/explore-analyze/alerts-cases/cases/manage-cases-settings.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Instructions for configuring case settings including closure options, custom fields, templates, and connectors. --- -# Manage case settings in {{kib}} [manage-cases-settings] +# Manage case settings [manage-cases-settings] -To change case closure options and add custom fields, templates, and connectors for external incident management systems, go to **{{stack-manage-app}} > Cases** and click **Settings**. +Configure case settings to customize how cases behave, including closure options, custom fields, templates for consistent case creation, and connectors for external incident management systems. Access case settings from **{{stack-manage-app}}** > **Cases** > **Settings**. To perform these tasks, you must have [full access](setup-cases.md) to the appropriate case and connector features in {{kib}}. diff --git a/explore-analyze/alerts-cases/cases/manage-cases.md b/explore-analyze/alerts-cases/cases/manage-cases.md index a079c774fc..7e5f1ce4c9 100644 --- a/explore-analyze/alerts-cases/cases/manage-cases.md +++ b/explore-analyze/alerts-cases/cases/manage-cases.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Instructions for creating, updating, and managing cases to track incidents and issues. --- -# Open and manage cases in {{kib}} [manage-cases] +# Open and manage cases [manage-cases] -To perform these tasks, you must have [full access](setup-cases.md) to the appropriate case features in {{kib}}. +You can create cases to track incidents and issues, add alerts and comments, assign team members, set severity and status, and send case information to external incident management systems. This page covers the core workflows for working with cases in **{{stack-manage-app}}**. ## Open a new case [open-case] diff --git a/explore-analyze/alerts-cases/cases/setup-cases.md b/explore-analyze/alerts-cases/cases/setup-cases.md index dead430097..1104d62edb 100644 --- a/explore-analyze/alerts-cases/cases/setup-cases.md +++ b/explore-analyze/alerts-cases/cases/setup-cases.md @@ -7,11 +7,12 @@ applies_to: serverless: ga products: - id: kibana +description: Instructions for configuring user privileges and access permissions for case management. --- -# Configure access to cases in {{kib}} [setup-cases] +# Configure access to cases [setup-cases] -To access cases in **{{stack-manage-app}}**, you must have the appropriate {{kib}} privileges: +To access and manage cases in **{{stack-manage-app}}**, users must have the appropriate {{kib}} feature privileges. You can grant full access to manage cases and settings, assignee access to work on cases, or read-only access to view cases. ## Give full access to manage cases and settings [_give_full_access_to_manage_cases_and_settings] diff --git a/explore-analyze/alerts-cases/watcher.md b/explore-analyze/alerts-cases/watcher.md index 4c3cec31a8..e64d58cb59 100644 --- a/explore-analyze/alerts-cases/watcher.md +++ b/explore-analyze/alerts-cases/watcher.md @@ -12,27 +12,30 @@ products: - id: elasticsearch - id: cloud-hosted - id: kibana +description: Overview of Watcher for creating custom alerting workflows with advanced scripting and transformations. --- -# Watcher +# {{watcher}} [watcher] ::::{tip} {{kib}} Alerting provides a set of built-in actions and alerts that are integrated with applications such as APM, Metrics, Security, and Uptime. You can use {{kib}} Alerting to detect complex conditions within different {{kib}} apps and trigger actions when those conditions are met. For more information, refer to [Alerts and Cases](../alerts-cases.md). :::: -You can use Watcher to watch for changes or anomalies in your data and perform the necessary actions in response. For example, you might want to: +{{watcher}} enables you to create sophisticated alerting workflows by watching for changes or anomalies in your data and performing automated actions in response. Using periodic {{product.elasticsearch}} queries, custom conditions, and flexible actions, {{watcher}} supports complex monitoring scenarios that require advanced scripting, data transformations, or custom logic beyond standard alerting rules. + +Common use cases: * Monitor social media as another way to detect failures in user-facing automated systems like ATMs or ticketing systems. When the number of tweets and posts in an area exceeds a threshold of significance, notify a service technician. * Monitor your infrastructure, tracking disk usage over time. Open a helpdesk ticket when any servers are likely to run out of free space in the next few days. * Track network activity to detect malicious activity, and proactively change firewall configuration to reject the malicious user. -* Monitor Elasticsearch, and send immediate notification to the system administrator if nodes leave the cluster or query throughput exceeds an expected range. +* Monitor {{product.elasticsearch}}, and send immediate notification to the system administrator if nodes leave the cluster or query throughput exceeds an expected range. * Track application response times and if page-load time exceeds SLAs for more than 5 minutes, open a helpdesk ticket. If SLAs are exceeded for an hour, page the administrator on duty. -All of these use-cases share a few key properties: +All of these use cases share a few key properties: -* The relevant data or changes in data can be identified with a periodic Elasticsearch query. +* The relevant data or changes in data can be identified with a periodic {{product.elasticsearch}} query. * The results of the query can be checked against a condition. -* One or more actions are taken if the condition is true — an email is sent, a 3rd party system is notified, or the query results are stored. +* One or more actions are taken if the condition is true — an email is sent, a third party system is notified, or the query results are stored. ## How watches work [_how_watches_work] @@ -44,12 +47,12 @@ Schedule : A schedule for running a query and checking the condition. Query -: The query to run as input to the condition. Watches support the full Elasticsearch query language, including aggregations. +: The query to run as input to the condition. Watches support the full {{product.elasticsearch}} query language, including aggregations. Condition : A condition that determines whether or not to execute the actions. You can use simple conditions (always true), or use scripting for more sophisticated scenarios. Actions -: One or more actions, such as sending email, pushing data to 3rd party systems through a webhook, or indexing the results of the query. +: One or more actions, such as sending email, pushing data to third party systems through a webhook, or indexing the results of the query. -A full history of all watches is maintained in an Elasticsearch index. This history keeps track of each time a watch is triggered and records the results from the query, whether the condition was met, and what actions were taken. +A full history of all watches is maintained in an {{product.elasticsearch}} index. This history keeps track of each time a watch is triggered and records the results from the query, whether the condition was met, and what actions were taken. diff --git a/explore-analyze/alerts-cases/watcher/action-conditions.md b/explore-analyze/alerts-cases/watcher/action-conditions.md index 2ddfb2d369..0fb11fa0df 100644 --- a/explore-analyze/alerts-cases/watcher/action-conditions.md +++ b/explore-analyze/alerts-cases/watcher/action-conditions.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Instructions for adding per-action conditions to execute different actions based on specific criteria. --- # Adding conditions to actions [action-conditions] -When a watch is triggered, its condition determines whether or not to execute the watch actions. Within each action, you can also add a condition per action. These additional conditions enable a single alert to execute different actions depending on a their respective conditions. The following watch would always send an email, when hits are found from the input search, but only trigger the `notify_pager` action when there are more than 5 hits in the search result. +When a watch is triggered, its condition determines whether to execute the watch actions. You can also add a condition to each individual action, enabling a single watch to execute different actions based on their respective conditions. For example, a watch could always send an email when hits are found but only trigger a pager notification when there are more than 5 hits. ```console PUT _watcher/watch/log_event_watch diff --git a/explore-analyze/alerts-cases/watcher/action-foreach.md b/explore-analyze/alerts-cases/watcher/action-foreach.md index 309d1ecb62..f65a0c9055 100644 --- a/explore-analyze/alerts-cases/watcher/action-foreach.md +++ b/explore-analyze/alerts-cases/watcher/action-foreach.md @@ -5,11 +5,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Instructions for using the foreach field to execute an action for each array element. --- # Running an action for each element in an array [action-foreach] -You can use the `foreach` field in an action to trigger the configured action for every element within that array. +You can use the `foreach` field in an action to trigger the configured action for every element within an array. To protect from long-running watches, you can use the `max_iterations` field to limit the maximum number of executions, which defaults to one hundred. In order to protect from long running watches, you can use the `max_iterations` field to limit the maximum amount of runs that each watch executes. If this limit is reached, the execution is gracefully stopped. If not set, this field defaults to one hundred. diff --git a/explore-analyze/alerts-cases/watcher/actions-email.md b/explore-analyze/alerts-cases/watcher/actions-email.md index 03945bf8fe..97821368ae 100644 --- a/explore-analyze/alerts-cases/watcher/actions-email.md +++ b/explore-analyze/alerts-cases/watcher/actions-email.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the email action that sends email notifications when watch conditions are met. --- # Email action [actions-email] -Use the `email` action to send email notifications. To send email, you must [configure at least one email account](#configuring-email) in `elasticsearch.yml`. +Use the **email** action to send email notifications when watch conditions are met. Email notifications can be plain text or HTML-styled, include information from the watch payload using templates, and attach the watch payload as a file. Email notifications can be plain text or styled using HTML. You can include information from the watch execution payload using [templates](how-watcher-works.md#templates) and attach the entire watch payload to the message. diff --git a/explore-analyze/alerts-cases/watcher/actions-index.md b/explore-analyze/alerts-cases/watcher/actions-index.md index cdf73d1c62..530ac849ee 100644 --- a/explore-analyze/alerts-cases/watcher/actions-index.md +++ b/explore-analyze/alerts-cases/watcher/actions-index.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the index action that indexes watch data into Elasticsearch. --- # Index action [actions-index] -Use the `index` action to index data into Elasticsearch. See [Index action attributes](#index-action-attributes) for the supported attributes. +Use the **index** action to index data into {{product.elasticsearch}} when watch conditions are met. This action enables you to store watch execution results, create audit trails, or populate indices with processed watch payload data. ## Configuring index actions [_configuring_index_actions] diff --git a/explore-analyze/alerts-cases/watcher/actions-jira.md b/explore-analyze/alerts-cases/watcher/actions-jira.md index b5c2ea0b0b..8d83440af4 100644 --- a/explore-analyze/alerts-cases/watcher/actions-jira.md +++ b/explore-analyze/alerts-cases/watcher/actions-jira.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the Jira action that creates issues in Atlassian Jira Software. --- # Jira action [actions-jira] -Use the `jira` action to create issues in [Atlassian’s Jira Software](https://www.atlassian.com/software/jira). To create issues you need to [configure at least one Jira account](#configuring-jira) in `elasticsearch.yml`. +Use the **Jira** action to create issues in Atlassian Jira Software when watch conditions are met. This action enables you to automatically generate Jira tickets, track incidents, and integrate {{watcher}} with your project management workflows. ## Configuring Jira actions [configuring-jira-actions] diff --git a/explore-analyze/alerts-cases/watcher/actions-logging.md b/explore-analyze/alerts-cases/watcher/actions-logging.md index 1a9a4d7a7d..693a6bac92 100644 --- a/explore-analyze/alerts-cases/watcher/actions-logging.md +++ b/explore-analyze/alerts-cases/watcher/actions-logging.md @@ -6,13 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the logging action that writes watch information to Elasticsearch logs. --- # Logging action [actions-logging] -Use the `logging` action to log text to the standard Elasticsearch logs. See [Logging action attributes](#logging-action-attributes) for the supported attributes. - -This action is primarily used during development and for debugging purposes. +Use the **logging** action to write text to the standard {{product.elasticsearch}} logs when watch conditions are met. This action is primarily used during development and debugging to verify watch execution and inspect payload data. ## Configuring logging actions [configuring-logging-actions] diff --git a/explore-analyze/alerts-cases/watcher/actions-pagerduty.md b/explore-analyze/alerts-cases/watcher/actions-pagerduty.md index 3c1bce9e7a..fa936f1101 100644 --- a/explore-analyze/alerts-cases/watcher/actions-pagerduty.md +++ b/explore-analyze/alerts-cases/watcher/actions-pagerduty.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the PagerDuty action that creates incidents and events in PagerDuty. --- # PagerDuty action [actions-pagerduty] -Use the PagerDuty action to create events in [ PagerDuty](https://pagerduty.com/). To create PagerDuty events, you must [configure at least one PagerDuty account](#configuring-pagerduty) in `elasticsearch.yml`. +Use the **PagerDuty** action to create events in PagerDuty when watch conditions are met. This action enables you to trigger PagerDuty incidents, route alerts to on-call teams, and integrate {{watcher}} with your incident response workflows. ## Configuring PagerDuty actions [configuring-pagerduty-actions] diff --git a/explore-analyze/alerts-cases/watcher/actions-slack.md b/explore-analyze/alerts-cases/watcher/actions-slack.md index d692099e3a..729b27332d 100644 --- a/explore-analyze/alerts-cases/watcher/actions-slack.md +++ b/explore-analyze/alerts-cases/watcher/actions-slack.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the Slack action that sends messages to Slack channels and users. --- # Slack action [actions-slack] -Use the `slack` action to send messages to a [Slack](https://slack.com/) team’s channels or users. To send Slack messages, you need to [configure at least one Slack account](#configuring-slack) in `elasticsearch.yml`. +Use the **Slack** action to send messages to Slack channels or users when watch conditions are met. You can format messages with Slack markdown, attach files, and customize message appearance to create effective team notifications. ## Configuring Slack actions [configuring-slack-actions] diff --git a/explore-analyze/alerts-cases/watcher/actions-webhook.md b/explore-analyze/alerts-cases/watcher/actions-webhook.md index 4b1f06bdd3..296bf79d15 100644 --- a/explore-analyze/alerts-cases/watcher/actions-webhook.md +++ b/explore-analyze/alerts-cases/watcher/actions-webhook.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the webhook action that sends HTTP/HTTPS requests to external web services. --- # Webhook action [actions-webhook] -Use the `webhook` action to send a request to any web service. The webhook action supports both HTTP and HTTPS connections. See [Webhook action attributes](#webhook-action-attributes) for the supported attributes. +Use the **webhook** action to send HTTP or HTTPS requests to any web service when watch conditions are met. This action enables integration with external systems, APIs, and custom endpoints that can receive and process watch payload data. ## Configuring webhook actions [configuring-webook-actions] diff --git a/explore-analyze/alerts-cases/watcher/actions.md b/explore-analyze/alerts-cases/watcher/actions.md index 2f2674431a..1cd74f684d 100644 --- a/explore-analyze/alerts-cases/watcher/actions.md +++ b/explore-analyze/alerts-cases/watcher/actions.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for action types that execute when watch conditions are met. --- -# Actions [actions] +# Watch actions [actions] -When a watch’s condition is met, its actions are executed unless it is being [throttled](#actions-ack-throttle). A watch can perform multiple actions. The actions are executed one at a time and each action executes independently. Any failures encountered while executing an action are recorded in the action result and in the watch history. +When a watch's condition is met, its actions are executed unless throttled. A watch can perform multiple actions, executed sequentially and independently. Actions have access to the watch payload and can use it to customize their behavior, such as using payload data to populate an email template. {{watcher}} supports email, webhook, index, logging, Slack, PagerDuty, and Jira actions. ::::{note} If no actions are defined for a watch, no actions are executed. However, a `watch_record` is still written to the watch history. diff --git a/explore-analyze/alerts-cases/watcher/condition-always.md b/explore-analyze/alerts-cases/watcher/condition-always.md index 721a599873..778d8ace1c 100644 --- a/explore-analyze/alerts-cases/watcher/condition-always.md +++ b/explore-analyze/alerts-cases/watcher/condition-always.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the always condition that executes watch actions on every trigger. --- # Always condition [condition-always] -Use the `always` condition to perform the watch actions whenever the watch is triggered, unless they are [throttled](actions.md#actions-ack-throttle). +Use the **always** condition to perform the watch actions whenever the watch is triggered, unless they are throttled. This condition is useful for executing actions on a fixed schedule, such as sending a weekly status report email. The `always` condition enables you to perform watch actions on a fixed schedule, such as, *"Every Friday at noon, send a status report email to `sys.admin@example.com`"* diff --git a/explore-analyze/alerts-cases/watcher/condition-array-compare.md b/explore-analyze/alerts-cases/watcher/condition-array-compare.md index 42deb8ba68..be265b3b2f 100644 --- a/explore-analyze/alerts-cases/watcher/condition-array-compare.md +++ b/explore-analyze/alerts-cases/watcher/condition-array-compare.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the array compare condition that evaluates array elements against a value. --- # Array compare condition [condition-array-compare] -Use `array_compare` to compare an array of values in the execution context to a given value. See [Table 84](condition-compare.md#condition-compare-operators) for the operators you can use. +Use the **array_compare** condition to compare an array of values in the execution context to a given value. This condition is useful for evaluating aggregation results or any array data where you need to check if at least one element meets specific criteria. ## Using an array compare condition [_using_an_array_compare_condition] diff --git a/explore-analyze/alerts-cases/watcher/condition-compare.md b/explore-analyze/alerts-cases/watcher/condition-compare.md index 235f0712e4..bb736d49a1 100644 --- a/explore-analyze/alerts-cases/watcher/condition-compare.md +++ b/explore-analyze/alerts-cases/watcher/condition-compare.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the compare condition that evaluates values using comparison operators. --- # Compare condition [condition-compare] -Use the `compare` condition to perform a simple comparison against a value in the watch payload. You can use the `compare` condition without enabling dynamic scripting. +Use the **compare** condition to perform a simple comparison against a value in the watch payload. You can use the compare condition without enabling dynamic scripting, making it a straightforward way to evaluate numeric, string, list, and object values. ## Compare condition operators [condition-compare-operators] diff --git a/explore-analyze/alerts-cases/watcher/condition-never.md b/explore-analyze/alerts-cases/watcher/condition-never.md index 69dbf53d58..3b9c9a88c2 100644 --- a/explore-analyze/alerts-cases/watcher/condition-never.md +++ b/explore-analyze/alerts-cases/watcher/condition-never.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the never condition that skips watch actions on every trigger. --- # Never condition [condition-never] -Use the `never` condition to skip performing the watch actions whenever the watch is triggered. The watch input is processed, a record is added to the watch history, and watch execution ends. This condition is generally used for testing. +Use the **never** condition to skip performing the watch actions whenever the watch is triggered. The watch input is processed and a record is added to the watch history, but watch execution ends without executing actions. This condition is generally used for testing. ## Using the never condition [_using_the_never_condition] diff --git a/explore-analyze/alerts-cases/watcher/condition-script.md b/explore-analyze/alerts-cases/watcher/condition-script.md index 2133ad4c5b..b1457580e0 100644 --- a/explore-analyze/alerts-cases/watcher/condition-script.md +++ b/explore-analyze/alerts-cases/watcher/condition-script.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the script condition that uses custom scripts to evaluate complex logic. --- # Script condition [condition-script] -A watch [condition](condition.md) that evaluates a script. The default scripting language is `painless`. You can use any of the scripting languages supported by Elasticsearch as long as the language supports evaluating expressions to Boolean values. Note that the `mustache` and `expression` languages are too limited to be used by this condition. For more information, see [Scripting](../../scripting.md). +Use the **script** condition to evaluate a script that determines whether to execute watch actions. The default scripting language is {{product.painless}}. You can use any scripting language supported by {{product.elasticsearch}} that can evaluate expressions to Boolean values, enabling complex conditional logic beyond simple comparisons. ## Using a script condition [_using_a_script_condition] diff --git a/explore-analyze/alerts-cases/watcher/condition.md b/explore-analyze/alerts-cases/watcher/condition.md index 2bb2949f74..f44316e8b2 100644 --- a/explore-analyze/alerts-cases/watcher/condition.md +++ b/explore-analyze/alerts-cases/watcher/condition.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for condition types that determine whether watch actions are executed. --- -# Conditions [condition] +# Watch conditions [condition] -When a watch is triggered, its condition determines whether or not to execute the watch actions. {{watcher}} supports the following condition types: +When a watch is triggered, its condition determines whether to execute the watch actions. Conditions have full access to the watch execution context, including the watch payload, enabling you to evaluate data before taking action. {{watcher}} supports five condition types: always, never, compare, array_compare, and script. * [`always`](condition-always.md): The condition always evaluates to `true`, so the watch actions are always performed. * [`never`](condition-never.md): The condition always evaluates to `false`, so the watch actions are never executed. diff --git a/explore-analyze/alerts-cases/watcher/enable-watcher.md b/explore-analyze/alerts-cases/watcher/enable-watcher.md index 2d7694556f..2bc86d56a1 100644 --- a/explore-analyze/alerts-cases/watcher/enable-watcher.md +++ b/explore-analyze/alerts-cases/watcher/enable-watcher.md @@ -5,9 +5,10 @@ applies_to: stack: ga products: - id: cloud-hosted +description: Instructions for enabling and configuring Watcher on Elastic Cloud deployments. --- -# Enable Watcher [enable-watcher] +# Enable {{watcher}} [enable-watcher] ::::{note} If you are looking for Kibana alerting, check [Alerts and Cases](../../../explore-analyze/alerts-cases.md). diff --git a/explore-analyze/alerts-cases/watcher/encrypting-data.md b/explore-analyze/alerts-cases/watcher/encrypting-data.md index 7f86282d32..01c7ae570b 100644 --- a/explore-analyze/alerts-cases/watcher/encrypting-data.md +++ b/explore-analyze/alerts-cases/watcher/encrypting-data.md @@ -5,11 +5,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Instructions for encrypting sensitive data like passwords and authentication credentials in watches. --- -# Encrypting sensitive data in Watcher [encrypting-data] +# Encrypting sensitive data in {{watcher}} [encrypting-data] -Watches might have access to sensitive data such as HTTP basic authentication information or details about your SMTP email service. You can encrypt this data by generating a key and adding some secure settings on each node in your cluster. +Watches might have access to sensitive data such as HTTP basic authentication information or details about your SMTP email service. You can encrypt this data by generating a system key and configuring secure settings on each node in your cluster. Once enabled, password fields in HTTP basic authentication blocks are stored encrypted rather than as plain text. Every `password` field that is used in your watch within an HTTP basic authentication block - for example within a webhook, an HTTP input or when using the reporting email attachment - will not be stored as plain text anymore. Also be aware, that there is no way to configure your own fields in a watch to be encrypted. diff --git a/explore-analyze/alerts-cases/watcher/example-watches.md b/explore-analyze/alerts-cases/watcher/example-watches.md index e26a488a09..e2da66fcfc 100644 --- a/explore-analyze/alerts-cases/watcher/example-watches.md +++ b/explore-analyze/alerts-cases/watcher/example-watches.md @@ -5,11 +5,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Collection of example watches demonstrating common monitoring scenarios. --- # Example watches [example-watches] -The following example shows how to set up a watch to: +The following examples demonstrate how to create watches for common monitoring scenarios: * [Monitor the status of an Elasticsearch cluster](watch-cluster-status.md) diff --git a/explore-analyze/alerts-cases/watcher/execute-watch.md b/explore-analyze/alerts-cases/watcher/execute-watch.md index f7b164f2a1..4bee4bf65e 100644 --- a/explore-analyze/alerts-cases/watcher/execute-watch.md +++ b/explore-analyze/alerts-cases/watcher/execute-watch.md @@ -5,11 +5,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Instructions for manually executing watches for testing and debugging purposes. --- # Execute a watch [execute-watch] -The [execute endpoint](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-watcher-execute-watch) lets you manually trigger the execution of a watch for testing or debugging purposes, without waiting for its scheduled trigger. You can simulate watch execution, override its input and condition, and control how individual actions behave during the run. +The execute watch endpoint lets you manually trigger watch execution for testing or debugging without waiting for its scheduled trigger. You can simulate watch execution, override its input and condition, and control how individual actions behave during the run. The examples below show how to execute an existing watch, customize its behavior during execution, and run an inline watch definition. diff --git a/explore-analyze/alerts-cases/watcher/how-watcher-works.md b/explore-analyze/alerts-cases/watcher/how-watcher-works.md index c26d23ede3..4855ef93e4 100644 --- a/explore-analyze/alerts-cases/watcher/how-watcher-works.md +++ b/explore-analyze/alerts-cases/watcher/how-watcher-works.md @@ -5,16 +5,15 @@ applies_to: stack: ga products: - id: elasticsearch +description: Explanation of watch components, execution flow, and how the watch payload works. --- -# How Watcher works [how-watcher-works] +# How {{watcher}} works [how-watcher-works] -You [add watches](#watch-definition) to automatically perform an action when certain conditions are met. The conditions are generally based on data you’ve loaded into the watch, also known as the *Watch Payload*. This payload can be loaded from different sources - from Elasticsearch, an external HTTP service, or even a combination of the two. +{{watcher}} automatically performs actions when certain conditions are met. Watches consist of a trigger, input, condition, and actions that work together to monitor data and respond to events. The watch payload—loaded from {{product.elasticsearch}}, an external HTTP service, or a combination of sources—provides the data evaluated by the condition. For example, you could configure a watch to send an email to the sysadmin when a search in the logs data indicates that there are too many 503 errors in the last 5 minutes. -This topic describes the elements of a watch and how watches operate. - ## Watch definition [watch-definition] diff --git a/explore-analyze/alerts-cases/watcher/input-chain.md b/explore-analyze/alerts-cases/watcher/input-chain.md index e38abad894..c226f99571 100644 --- a/explore-analyze/alerts-cases/watcher/input-chain.md +++ b/explore-analyze/alerts-cases/watcher/input-chain.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the chain input type that loads data from multiple sources sequentially. --- # Chain input [input-chain] -Use the `chain` input to load data from multiple sources into the watch execution context when the watch is triggered. The inputs in a chain are processed in order and the data loaded by an input can be accessed by the subsequent inputs in the chain. +Use the **chain** input to load data from multiple sources into the watch execution context when the watch is triggered. The inputs in a chain are processed sequentially, and data loaded by one input can be accessed by subsequent inputs in the chain, enabling you to build on previous results or combine data from different sources. The `chain` input enables you to perform actions based on data from multiple sources. You can also use the data collected by one input to load data from another source. diff --git a/explore-analyze/alerts-cases/watcher/input-http.md b/explore-analyze/alerts-cases/watcher/input-http.md index 66ed102288..227222e181 100644 --- a/explore-analyze/alerts-cases/watcher/input-http.md +++ b/explore-analyze/alerts-cases/watcher/input-http.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the HTTP input type that loads data from HTTP endpoints into watch execution context. --- # HTTP input [input-http] -Use the `http` input to submit a request to an HTTP endpoint and load the response into the watch execution context when the watch is triggered. See [HTTP input attributes](#http-input-attributes) for all of the supported attributes. +Use the **HTTP** input to submit a request to an HTTP endpoint and load the response into the watch execution context when the watch is triggered. This input type enables you to query external {{product.elasticsearch}} clusters, access {{product.elasticsearch}} APIs beyond search, and retrieve data from any web service that exposes an HTTP endpoint. With the `http` input, you can: diff --git a/explore-analyze/alerts-cases/watcher/input-search.md b/explore-analyze/alerts-cases/watcher/input-search.md index be6c02b138..72816a2cf8 100644 --- a/explore-analyze/alerts-cases/watcher/input-search.md +++ b/explore-analyze/alerts-cases/watcher/input-search.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the search input type that loads Elasticsearch query results into watch execution context. --- # Search input [input-search] -Use the `search` input to load the results of an Elasticsearch search request into the execution context when the watch is triggered. See [Search Input Attributes](#search-input-attributes) for all of the supported attributes. +Use the **search** input to load the results of an {{product.elasticsearch}} search request into the execution context when the watch is triggered. The search request body supports the full {{product.elasticsearch}} Query DSL, enabling you to retrieve and analyze any data indexed in your cluster. In the search input’s `request` object, you specify: diff --git a/explore-analyze/alerts-cases/watcher/input-simple.md b/explore-analyze/alerts-cases/watcher/input-simple.md index fabe5ab260..d16a0e0c4f 100644 --- a/explore-analyze/alerts-cases/watcher/input-simple.md +++ b/explore-analyze/alerts-cases/watcher/input-simple.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the simple input type that loads static data into watch execution context. --- # Simple input [input-simple] -Use the `simple` input to load static data into the execution context when the watch is triggered. This enables you to store the data centrally and reference it with templates. +Use the **simple** input to load static data into the execution context when the watch is triggered. This input type enables you to store data centrally and reference it with templates, making it useful for configuration values, recipient lists, or other static information used by watch conditions and actions. You can define the static data as a string (`str`), numeric value (`num`), or an object (`obj`): diff --git a/explore-analyze/alerts-cases/watcher/input.md b/explore-analyze/alerts-cases/watcher/input.md index c1960ab028..08c19e28f4 100644 --- a/explore-analyze/alerts-cases/watcher/input.md +++ b/explore-analyze/alerts-cases/watcher/input.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for watch input types that load data into the execution context. --- -# Inputs [input] +# Watch inputs [input] -When a watch is triggered, its *input* loads data into the execution context. This payload is accessible during the subsequent watch execution phases. For example, you can base a watch’s condition on the data loaded by its input. +When a watch is triggered, its input loads data into the execution context, making the payload accessible during subsequent watch execution phases. You can use this data to evaluate conditions and pass information to actions. {{watcher}} supports four input types: simple, search, HTTP, and chain. {{watcher}} supports four input types: diff --git a/explore-analyze/alerts-cases/watcher/managing-watches.md b/explore-analyze/alerts-cases/watcher/managing-watches.md index 28facb9481..72de9c49ed 100644 --- a/explore-analyze/alerts-cases/watcher/managing-watches.md +++ b/explore-analyze/alerts-cases/watcher/managing-watches.md @@ -5,11 +5,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the APIs used to create, update, activate, deactivate, and delete watches. --- # Managing watches [managing-watches] -{{watcher}} provides as set of APIs you can use to manage your watches: +{{watcher}} provides a set of APIs you can use to manage your watches, including operations to create, update, retrieve, activate, deactivate, acknowledge, and delete watches. You can also list watches by querying the `.watches` index. * Use the [create or update watch API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-watcher-put-watch) to add or update watches * Use the [get watch API](https://www.elastic.co/docs/api/doc/elasticsearch/operation/operation-watcher-get-watch) to retrieve watches diff --git a/explore-analyze/alerts-cases/watcher/schedule-types.md b/explore-analyze/alerts-cases/watcher/schedule-types.md index c4ef118eb9..01c979231f 100644 --- a/explore-analyze/alerts-cases/watcher/schedule-types.md +++ b/explore-analyze/alerts-cases/watcher/schedule-types.md @@ -5,11 +5,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for schedule types including hourly, daily, weekly, monthly, yearly, cron, and interval. --- -# Schedule Types [_schedule_types] +# Schedule types [_schedule_types] -{{watcher}} provides several types of schedule triggers: +{{watcher}} provides several types of schedule triggers for different time-based execution patterns. Choose the schedule type that best matches your monitoring needs, from simple hourly schedules to complex cron expressions. * [`hourly`](#schedule-hourly) * [`daily`](#schedule-daily) diff --git a/explore-analyze/alerts-cases/watcher/throttling.md b/explore-analyze/alerts-cases/watcher/throttling.md index 5eca77d0e0..ace09bae44 100644 --- a/explore-analyze/alerts-cases/watcher/throttling.md +++ b/explore-analyze/alerts-cases/watcher/throttling.md @@ -5,9 +5,10 @@ applies_to: stack: ga products: - id: elasticsearch +description: Explanation of how throttling affects watch execution frequency and scheduling. --- # Throttling [_throttling] -Keep in mind that the throttle period can affect when a watch is actually executed. The default throttle period is five seconds (5000 ms). If you configure a schedule that’s more frequent than the throttle period, the throttle period overrides the schedule. For example, if you set the throttle period to one minute (60000 ms) and set the schedule to every 10 seconds, the watch is executed no more than once per minute. For more information about throttling, see [Acknowledgement and throttling](actions.md#actions-ack-throttle). +The throttle period can affect when a watch is actually executed. The default throttle period is five seconds (5000 ms). If you configure a schedule that's more frequent than the throttle period, the throttle period overrides the schedule, limiting how often the watch can run. For example, if you set the throttle period to one minute (60000 ms) and set the schedule to every 10 seconds, the watch executes no more than once per minute. diff --git a/explore-analyze/alerts-cases/watcher/transform-chain.md b/explore-analyze/alerts-cases/watcher/transform-chain.md index a43969276c..d04dd3def2 100644 --- a/explore-analyze/alerts-cases/watcher/transform-chain.md +++ b/explore-analyze/alerts-cases/watcher/transform-chain.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the chain transform that executes multiple transforms sequentially. --- # Chain payload transform [transform-chain] -A [{{watcher-transform}}](transform.md) that executes an ordered list of configured {{watcher-transforms}} in a chain, where the output of one transform serves as the input of the next transform in the chain. The payload that is accepted by this transform serves as the input of the first transform in the chain and the output of the last transform in the chain is the output of the `chain` transform as a whole. +Use the **chain** {{watcher-transform}} to execute an ordered list of transforms sequentially, where the output of one transform serves as the input of the next. This transform enables you to build complex data processing pipelines by combining search, script, and other chain transforms. You can use chain {{watcher-transforms}} to build more complex transforms out of the other available transforms. For example, you can combine a [`search`](transform-search.md) {{watcher-transform}} and a [`script`](transform-script.md) {{watcher-transform}}, as shown in the following snippet: diff --git a/explore-analyze/alerts-cases/watcher/transform-script.md b/explore-analyze/alerts-cases/watcher/transform-script.md index fe522db298..a4b812b69b 100644 --- a/explore-analyze/alerts-cases/watcher/transform-script.md +++ b/explore-analyze/alerts-cases/watcher/transform-script.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the script transform that uses custom scripts to modify payload data. --- # Script payload transform [transform-script] -A [{{watcher-transform}}](transform.md) that executes a script on the current payload in the watch execution context and replaces it with a newly generated one. The following snippet shows how a simple script {{watcher-transform}} can be defined on the watch level: +Use the **script** {{watcher-transform}} to execute a script that modifies the current payload in the watch execution context. This transform enables you to extract specific fields, calculate derived values, or restructure data before actions are executed. ::::{tip} The `script` {{watcher-transform}} is often useful when used in combination with the [`search`](transform-search.md) {{watcher-transform}}, where the script can extract only the significant data from a search result, and by that, keep the payload minimal. This can be achieved with the [`chain`](transform-chain.md) {{watcher-transform}}. diff --git a/explore-analyze/alerts-cases/watcher/transform-search.md b/explore-analyze/alerts-cases/watcher/transform-search.md index 5b2b2a63e9..ebe5a02b31 100644 --- a/explore-analyze/alerts-cases/watcher/transform-search.md +++ b/explore-analyze/alerts-cases/watcher/transform-search.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for the search transform that replaces payload with search results. --- # Search payload transform [transform-search] -A [{{watcher-transform}}](transform.md) that executes a search on the cluster and replaces the current payload in the watch execution context with the returned search response. The following snippet shows how a simple search transform can be defined on the watch level: +Use the **search** {{watcher-transform}} to execute a search on the cluster and replace the current payload in the watch execution context with the returned search response. This transform enables you to load additional data or refine existing data before actions are executed. ```js { diff --git a/explore-analyze/alerts-cases/watcher/transform.md b/explore-analyze/alerts-cases/watcher/transform.md index 4fc9b3181e..5c6d9a3099 100644 --- a/explore-analyze/alerts-cases/watcher/transform.md +++ b/explore-analyze/alerts-cases/watcher/transform.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for transforms that process and modify watch payload data. --- -# Transforms [transform] +# Watch transforms [transform] -A *{{watcher-transform}}* processes and changes the payload in the watch execution context to prepare it for the watch actions. {{watcher}} supports three types of {{watcher-transforms}}: +A {{watcher-transform}} processes and changes the payload in the watch execution context to prepare it for the watch actions. You can define transforms at the watch level to apply to all actions, or per action for action-specific payload preparation. {{watcher}} supports three transform types: search, script, and chain. * [`search`](transform-search.md) * [`script`](transform-script.md) diff --git a/explore-analyze/alerts-cases/watcher/trigger-schedule.md b/explore-analyze/alerts-cases/watcher/trigger-schedule.md index 8d197b69f9..8f343cb6fc 100644 --- a/explore-analyze/alerts-cases/watcher/trigger-schedule.md +++ b/explore-analyze/alerts-cases/watcher/trigger-schedule.md @@ -6,11 +6,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for schedule triggers that define time-based watch execution. --- # Schedule trigger [trigger-schedule] -Schedule [triggers](trigger.md) define when the watch execution should start based on date and time. All times are in UTC time unless a timezone is explicitly specified in the schedule. +Schedule triggers define when watch execution should start based on date and time. All times are in UTC unless a timezone is explicitly specified in the schedule. {{watcher}} uses the system clock to determine the current time, so you should synchronize the clocks of all nodes in the cluster using a time service such as NTP. {{watcher}} uses the system clock to determine the current time. To ensure schedules are triggered when expected, you should synchronize the clocks of all nodes in the cluster using a time service such as [NTP](http://www.ntp.org/). diff --git a/explore-analyze/alerts-cases/watcher/trigger.md b/explore-analyze/alerts-cases/watcher/trigger.md index e87e9385a1..7e1df52519 100644 --- a/explore-analyze/alerts-cases/watcher/trigger.md +++ b/explore-analyze/alerts-cases/watcher/trigger.md @@ -6,10 +6,11 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference for watch triggers that define when watch execution starts. --- -# Triggers [trigger] +# Watch triggers [trigger] -Every watch must have a `trigger` that defines when the watch execution process should start. When you create a watch, its trigger is registered with the appropriate *Trigger Engine*. The trigger engine is responsible for evaluating the trigger and triggering the watch when needed. +Every watch must have a trigger that defines when the watch execution process should start. When you create a watch, its trigger is registered with the trigger engine, which evaluates the trigger and starts the watch when conditions are met. {{watcher}} currently supports time-based schedule triggers. {{watcher}} is designed to support different types of triggers, but only time-based [`schedule`](trigger-schedule.md) triggers are currently available. diff --git a/explore-analyze/alerts-cases/watcher/watch-cluster-status.md b/explore-analyze/alerts-cases/watcher/watch-cluster-status.md index 4f4ea0a8b2..bcbfa86ad3 100644 --- a/explore-analyze/alerts-cases/watcher/watch-cluster-status.md +++ b/explore-analyze/alerts-cases/watcher/watch-cluster-status.md @@ -5,11 +5,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Example watch that monitors Elasticsearch cluster health status. --- -# Watching the status of an Elasticsearch cluster [watch-cluster-status] +# Watching the status of an {{product.elasticsearch}} cluster [watch-cluster-status] -You can easily configure a basic watch to monitor the health of your Elasticsearch cluster: +You can configure a basic watch to monitor the health of your {{product.elasticsearch}} cluster and send notifications when the cluster status changes: * [Schedule the watch and define an input](#health-add-input) that gets the cluster health status. * [Add a condition](#health-add-condition) that evaluates the health status to determine if action is required. diff --git a/explore-analyze/alerts-cases/watcher/watcher-getting-started.md b/explore-analyze/alerts-cases/watcher/watcher-getting-started.md index e62aaf2b46..eb12db52e4 100644 --- a/explore-analyze/alerts-cases/watcher/watcher-getting-started.md +++ b/explore-analyze/alerts-cases/watcher/watcher-getting-started.md @@ -5,11 +5,12 @@ applies_to: stack: ga products: - id: elasticsearch +description: Step-by-step tutorial for creating your first watch with schedule, input, condition, and action. --- -# Getting started with Watcher [watcher-getting-started] +# Getting started with {{watcher}} [watcher-getting-started] -To set up a watch to start sending alerts: +To set up a watch that sends alerts when conditions are met, you define a schedule to check the data, an input to load the data, a condition to evaluate, and an action to execute. This tutorial walks through creating a basic watch that monitors log data for errors. * [Schedule the watch and define an input](#log-add-input). * [Add a condition](#log-add-condition) that checks to see if an alert needs to be sent. diff --git a/explore-analyze/alerts-cases/watcher/watcher-limitations.md b/explore-analyze/alerts-cases/watcher/watcher-limitations.md index 094896c2aa..e55dc17a50 100644 --- a/explore-analyze/alerts-cases/watcher/watcher-limitations.md +++ b/explore-analyze/alerts-cases/watcher/watcher-limitations.md @@ -6,9 +6,10 @@ applies_to: stack: ga products: - id: elasticsearch +description: Reference of known limitations and constraints when using Watcher. --- -# Watcher limitations [watcher-limitations] +# {{watcher}} limitations [watcher-limitations] ## Watches are not updated when file based scripts change [_watches_are_not_updated_when_file_based_scripts_change] diff --git a/explore-analyze/alerts-cases/watcher/watcher-ui.md b/explore-analyze/alerts-cases/watcher/watcher-ui.md index c4d119a280..1366766192 100644 --- a/explore-analyze/alerts-cases/watcher/watcher-ui.md +++ b/explore-analyze/alerts-cases/watcher/watcher-ui.md @@ -1,11 +1,14 @@ --- applies_to: stack: ga +products: + - id: kibana +description: Instructions for using the Watcher UI to create, manage, and monitor watches. --- -# Watcher UI [watcher-ui] +# {{watcher}} UI [watcher-ui] -Go to the **Watcher** page using the navigation menu or the [global search field](/explore-analyze/find-and-organize/find-apps-and-objects.md). With this UI, you can: +Access the **{{watcher}}** page from the navigation menu or the global search field to create, manage, and monitor your watches. The UI provides tools for creating threshold watches, viewing watch history and action status, and managing watch lifecycle. * [Create a simple threshold watch](#watcher-create-threshold-alert) * [View your watch history and action status](#watcher-getting-started) From bf26544b95d1a3c13ff411ebdac93588890c4657 Mon Sep 17 00:00:00 2001 From: Florent Le Borgne Date: Wed, 26 Nov 2025 15:01:27 +0100 Subject: [PATCH 2/2] variables --- explore-analyze/alerts-cases.md | 4 ++-- explore-analyze/alerts-cases/alerts/maintenance-windows.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/explore-analyze/alerts-cases.md b/explore-analyze/alerts-cases.md index c7de70b4f0..47c98c0678 100644 --- a/explore-analyze/alerts-cases.md +++ b/explore-analyze/alerts-cases.md @@ -23,9 +23,9 @@ Alerts are notifications generated when specific conditions are met. These notif Cases are a collaboration and tracking tool, which is particularly useful for incidents or issues that arise from alerts. You can group related alerts into a case for easier management, add notes and comments to provide context, track investigation progress, and assign cases to team members or link them to external systems. Cases ensure that teams have a central place to track and resolve alerts efficiently. -## {{maint-windows-cap}} [maintenance-windows-overview] +## Maintenance windows [maintenance-windows-overview] -If you have a planned outage, {{maint-windows}} prevent rules from generating notifications in that period. Alerts still occur but their notifications are suppressed. +If you have a planned outage, maintenance windows prevent rules from generating notifications in that period. Alerts still occur but their notifications are suppressed. ### Workflow example [workflow-example] diff --git a/explore-analyze/alerts-cases/alerts/maintenance-windows.md b/explore-analyze/alerts-cases/alerts/maintenance-windows.md index 2c61d330f4..89e93f3465 100644 --- a/explore-analyze/alerts-cases/alerts/maintenance-windows.md +++ b/explore-analyze/alerts-cases/alerts/maintenance-windows.md @@ -11,12 +11,12 @@ products: description: Instructions for scheduling maintenance windows to suppress rule notifications during planned outages. --- -# {{maint-windows-cap}} [maintenance-windows] +# Maintenance windows [maintenance-windows] This content applies to: [![Observability](/explore-analyze/images/serverless-obs-badge.svg "")](../../../solutions/observability.md) [![Security](/explore-analyze/images/serverless-sec-badge.svg "")](../../../solutions/security.md) -You can schedule single or recurring {{maint-windows}} to temporarily suppress rule notifications during planned outages or maintenance periods. Alerts continue to be generated, but notifications are suppressed according to the maintenance window schedule. +You can schedule single or recurring maintenance windows to temporarily suppress rule notifications during planned outages or maintenance periods. Alerts continue to be generated, but notifications are suppressed according to the maintenance window schedule. By default, a maintenance window affects all rules in all {{kib}} apps within its space. You can refine the scope of a maintenance window by adding filters and rule categories.