How the experimental alerting system works

This page walks through what happens at each step after a rule runs on its schedule. Both paths begin the same way: Kibana writes a rule event for each matching row. The rule's configuration determines whether those events are grouped into an alert episode. In the UI, that setting is Rule mode. Use this page to understand how the different components of the experimental alerting system interact.

When matches are grouped into an alert episode, Kibana writes each match as a rule event (type: alert) with episode.* fields. Events that share an episode.id form the episode, which persists and tracks the problem until the condition clears. Each new event can advance the episode's lifecycle state. An action policy sits between the episode and a workflow, deciding whether and when to invoke it. In the UI, set this configuration with Rule mode.

Step Actor Action
1 Rule Runs on schedule and evaluates ES|QL against your data
2 Kibana Query returns results → Writes one rule event per matching row to .rule-events (type: alert)
3 Kibana Groups the event into an alert episode. Events that share an episode.id form the episode. The episode opens in pending and advances to active once the activation threshold is met
4 Action policy Evaluates the episode against its conditions (checks for episode eligibility, match conditions, and frequency)
5 Action policy If conditions are met, invokes a workflow
6 Workflow Sends notification or runs automation
7 Kibana Condition clears → Writes a new rule event → Episode moves to recovering → inactive
8 Action policy Evaluates recovery event and invokes a workflow if conditions are met
9 Workflow Sends the recovery notification
Note

Steps 4–6 and 8–9 run on a separate background process that polls roughly every 5 seconds. Action policy evaluation is not triggered synchronously by the rule's own execution. There is always at least one dispatcher polling cycle between a rule run and any resulting notification.

An SRE team wants to know when checkout service latency degrades, and notify the on-call team when it does. The team creates a rule that groups matches into an alert episode:

  1. The rule runs an ES|QL query every five minutes, checking p95 checkout service latency.
  2. When p95 exceeds 2 seconds for more than one consecutive check, those events form an alert episode.
  3. An action policy with a rule.tags: "checkout" matcher skips low-severity episodes and invokes an on-call workflow that sends a Slack message.

The engineer investigates, fixes a slow query, and the alert episode recovers automatically.

Kibana writes a rule event (type: signal) to .rule-events for each match. Action policies evaluate alert episodes only, so the event never reaches a policy or a workflow. Those events accumulate over time and are immediately queryable in Discover for incident investigation, or as inputs to a follow-on rule that groups matches into an episode. In the UI, set this configuration with Rule mode. For query examples, dashboards, and correlation patterns, refer to Query signals.

Step Actor Action
1 Rule Runs on schedule and evaluates ES|QL against your data
2 Kibana Query returns results → Writes one rule event per matching row to .rule-events (type: signal)
3 Kibana Leaves the event available for later analysis. Action policies evaluate alert episodes only, so this event never reaches a policy or a workflow

A security team wants to track calls to a rarely-used administrator API endpoint, but individual calls aren't suspicious enough to page anyone. To start collecting data without generating noise, the team creates a rule that records rule events:

  1. The rule runs an ES|QL query on a schedule, checking for calls to the administrator API endpoint.
  2. Each time the query returns results, Kibana writes a rule event (type: signal) to .rule-events.
  3. The events accumulate silently and are immediately queryable in Discover.

After a few weeks, the accumulated events become useful in two ways. The team can write a follow-on rule that groups matches into an episode and combines admin API calls with other events (such as a spike in error rates) to catch correlated activity that neither source would surface on its own. When an outage happens, the team can query that history as evidence directly in Discover, without reconstructing the original query or worrying that the source data has become stale.

  • Get started: Enable the experimental alerting system and create your first rule.
  • Rules: What rules do, what they don't control, and how to choose a creation path.
  • Rule events: What Kibana writes to .rule-events and how those events relate to alert episodes.
  • Query signals: Query events with type: signal in Discover and use them as input to a rule that opens an episode.
  • Notifications and actions: Set up workflows and action policies to notify your team when an alert episode matches.