Experimental alerting system overview

The experimental alerting system in Kibana watches your Elasticsearch data continuously, so your team doesn't have to. You define the conditions that matter, and the system handles detection, tracking, and notification from there.

Note

In the generally available Kibana alerting system, the term alert refers to a tracked occurrence of a rule condition. In the experimental alerting system, the equivalent concept is called an alert episode. Each system's APIs, UI, and instructions apply only to that system's concepts.

The experimental alerting system starts with a rule evaluating your data on a schedule. When the rule detects a match, Kibana writes a rule event to .rule-events. The rule's configuration determines whether those events are grouped into an alert episode. Events that aren't part of an episode remain available for later analysis.

Flowchart showing a rule detecting a match, Kibana writing a rule event, then either grouping that event into an alert episode or leaving it with no episode for later analysis

The experimental alerting system is built around five objects: rules, rule events, alert episodes, action policies, and workflows, each with a distinct role.

A rule defines what to watch for in your data and how often to check. On each run, Kibana writes matches as rule events.

Refer to Rules to learn more.

A rule event is the document Kibana writes to .rule-events for each match. The rule's configuration determines whether those events are grouped into an alert episode.

Refer to Rule events and Query signals to learn more.

An alert episode tracks one problem from first detection through recovery, so you triage one lifecycle per problem.

Refer to Alert episodes to learn more.

An action policy decides whether and when to invoke a workflow for an alert episode. Notifications are configured on the policy, not on the rule, so you can update where they're sent without editing each rule.

Refer to Notifications and actions to learn more.

A workflow sends the notification or runs the automation, for example posting to Slack, sending an email, or calling a webhook.

Refer to Connect workflows to learn more.

Together, these building blocks form two main paths, which diverge based on the rule's configuration:

  1. A rule evaluates your data on a schedule and detects a match.

  2. Kibana writes the match as a rule event to .rule-events.

  3. The rule's configuration determines the next step:

    • Alert episode - Kibana groups the event into an episode. An action policy evaluates the episode and can invoke a workflow, which sends the notification or runs the automation.

    • No episode - The event remains available for later analysis. You can query it, build dashboards, or feed it into another rule. Action policies evaluate alert episodes only, so this event never reaches a policy or a workflow.

Flowchart showing a rule detecting a match, Kibana writing a rule event, then either grouping the event into an alert episode that an action policy can route to a workflow, or leaving the event with no episode for later analysis
  • New to the experimental alerting system? Get started walks you through enabling the system, setting up role access, and creating your first rule with a hands-on tutorial.
  • Wondering what you can detect? Rules shows you how to define what to watch for in ES|QL, and how to choose and configure the right creation path for your use case.
  • Curious what happens when something breaks? Alerts explains how alert episodes track a problem from first detection through recovery, and how to triage them as they come in.
  • Want the right people to know when it matters? Notifications and actions shows you how workflows and action policies decide who gets notified, and when.