Skip to content
Draft
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion .gitignore
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
21 changes: 11 additions & 10 deletions explore-analyze/alerts-cases.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,36 +8,37 @@
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
## Maintenance windows [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.

### 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]

Check notice on line 39 in explore-analyze/alerts-cases.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.Capitalization: '[watcher-overview]' should use sentence-style capitalization.
```{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.
5 changes: 4 additions & 1 deletion explore-analyze/alerts-cases/alerts.md
Original file line number Diff line number Diff line change
Expand Up @@ -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]

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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]

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
5 changes: 3 additions & 2 deletions explore-analyze/alerts-cases/alerts/alerting-setup.md
Original file line number Diff line number Diff line change
Expand Up @@ -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]

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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]

Expand Down
5 changes: 3 additions & 2 deletions explore-analyze/alerts-cases/alerts/create-manage-rules.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,12 @@
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.

Check notice on line 15 in explore-analyze/alerts-cases/alerts/create-manage-rules.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.WordChoice: Consider using 'turn off, silence' instead of 'mute', unless the term is in the UI.

Check notice on line 15 in explore-analyze/alerts-cases/alerts/create-manage-rules.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.WordChoice: Consider using 'deactivate, deselect, hide, turn off' instead of 'disable', unless the term is in the UI.

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).

Expand Down
1 change: 1 addition & 0 deletions explore-analyze/alerts-cases/alerts/event-log-index.md
Original file line number Diff line number Diff line change
Expand Up @@ -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]
Expand Down
5 changes: 3 additions & 2 deletions explore-analyze/alerts-cases/alerts/geo-alerting.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
5 changes: 3 additions & 2 deletions explore-analyze/alerts-cases/alerts/maintenance-windows.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
# 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 maintenance windows to temporarily reduce rule notifications. For example, a maintenance window prevents false alarms during planned outages.
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.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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).
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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]

Expand Down
5 changes: 3 additions & 2 deletions explore-analyze/alerts-cases/alerts/rule-type-es-query.md
Original file line number Diff line number Diff line change
Expand Up @@ -7,11 +7,12 @@
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]

Check notice on line 13 in explore-analyze/alerts-cases/alerts/rule-type-es-query.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.Capitalization: 'query rule [rule-type-es-query]' should use sentence-style capitalization.

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.

Check notice on line 15 in explore-analyze/alerts-cases/alerts/rule-type-es-query.md

View workflow job for this annotation

GitHub Actions / vale

Elastic.Acronyms: 'DSL' has no definition.

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.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.

Expand Down
3 changes: 2 additions & 1 deletion explore-analyze/alerts-cases/alerts/rule-types.md
Original file line number Diff line number Diff line change
Expand Up @@ -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).
Expand Down
3 changes: 2 additions & 1 deletion explore-analyze/alerts-cases/alerts/testing-connectors.md
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
5 changes: 3 additions & 2 deletions explore-analyze/alerts-cases/alerts/view-alerts.md
Original file line number Diff line number Diff line change
Expand Up @@ -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**.

Expand Down
Loading
Loading