Loading

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, such as when to open an issue, who should know, and how often to notify them. The system handles the rest.

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. The two terms describe similar ideas in different systems and are not interchangeable.

The experimental alerting system separates detecting a problem from acting on it:

  • Detecting - Rules focus purely on what to watch for in your data and on collecting breach and recovery events.
  • Acting - Action policies handle who gets notified, when, and how, independently of any rule.

You can build and test detection logic before wiring up any notifications, and update notification routing across all rules in one place without editing the rules themselves.

The experimental alerting system is built around four objects: rules, 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. Every rule runs in one of two modes: alert or signal.

  • Alert - Opens an alert episode when the rule finds a match and closes it when the condition clears, notifying your team at each episode state change. Helpful when you want to follow a problem from first detection to resolution.
  • Signal - Records rule query results over time without opening episodes or sending notifications. Helps you build a baseline, spot trends, or collect evidence before deciding whether something is worth alerting on.

In Alert mode, the rule opens one alert episode per problem and keeps it open until the condition clears. The alert episode moves through states (pending, active, recovering, inactive) giving you one lifecycle to triage rather than a separate item per rule check.

An action policy is the gating layer between an alert episode and a workflow. It decides whether and when to invoke a workflow by evaluating suppression, match conditions, and frequency. Policy configuration determines the scope. A policy can apply to alert episodes from a specific rule, multiple rules, or all rules in the space.

A workflow is what actually sends the message or runs the automation, for example, posting to Slack, sending an email, calling a webhook. The experimental alerting system invokes workflows through action policies that you configure to trigger on a schedule or on a state change on an alert episode.

At the simplest level:

  1. A rule checks your data on a schedule.
  2. The rule's query returns results when data matching its conditions is found.
  3. The rule's mode determines what happens next:
    • Alert - The rule opens an alert episode to track the problem. An action policy can route it to a workflow to perform an action or send a notification.
    • Signal - Each result is recorded for querying later. Nothing else happens.

For a more detailed explanation of each stage, refer to How the experimental alerting system works.

To understand how the experimental alerting system fits into Kibana's alerting options, refer to Alerting or Compare alerting systems.