---
title: Configure a rule in experimental alerting system
description: Configure rules in the experimental alerting system: mode, ES|QL, grouping, schedule, lookback, activation and recovery, no-data handling, tags, and evaluation.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6523/explore-analyze/alerting/kibana-alerting-experimental/rules/configure-a-rule
products:
- Kibana
applies_to:
- Elastic Cloud Serverless: Experimental
- Elastic Stack: Planned
---
# Configure a rule in experimental alerting system
Rule configuration is part of the experimental alerting system in Kibana. The ES|QL query defines what a rule detects. The settings on this page determine whether it behaves correctly in production: how often it runs, how it groups related problems, when it opens and closes alerts, and what it does when data stops arriving.
For query authoring, refer to [Author rules](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6523/explore-analyze/alerting/kibana-alerting-experimental/rules/author-rules).
For Alert-mode rules, you can create and attach action policies directly from the rule form's **Actions** step. Existing action policies that match the rule are listed on load. If none exist, an onboarding panel appears. Action policies are created or updated alongside the rule when you save. The **Actions** step is not shown for Signal-mode rules.You can also manage action policies independently from the **Action policies** area, using KQL matchers to scope them to any episodes you want to route.
## Rule mode
Choose a mode that matches how you want to use results:
| Mode | Behavior |
|--------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Signal | Signals only: the rule produces detections without alert lifecycle tracking or notifications. |
| Alert | Lifecycle tracking and actions. Alerts move through states (pending, active, recovering, and so on), and you can attach action policies so alert episodes dispatch through workflows. |
Several settings on this page apply only when the rule is in Alert mode (`kind: alert`).
## ES|QL query
The rule's ES|QL query defines what to evaluate. It has a base query and an optional alert condition. Together they drive which rows become alert events and how no-data behavior applies. See [ES|QL query structure](/elastic/docs-content/pull/6523/explore-analyze/alerting/kibana-alerting-experimental/rules/author-rules#esql-query-structure) for how those pieces interact with no-data behavior and `KEEP`.
## Rule grouping
Rule grouping splits alert event generation by one or more group key fields so that each unique combination of field values produces its own alert series. Each series has independent lifecycle tracking, recovery detection, and per-series snooze.
Group key fields must align with the `BY` clause in your ES|QL query's `STATS` command. See [Author rules](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6523/explore-analyze/alerting/kibana-alerting-experimental/rules/author-rules) for query patterns.
When writing a rule that uses grouping, writing the query first and then specifying group fields avoids mismatches between the query output and the grouping configuration. The group fields in the rule form reflect the columns produced by the `STATS ... BY` clause, so if you add or remove a `BY` field in the query, the corresponding group field must be updated to match.
Note that rule grouping is separate from notification grouping on an action policy, which controls how alert episodes batch into messages.
## Schedule and lookback
The schedule and lookback settings control how often a rule runs and how far back it looks when evaluating data.
### Execution interval
The execution interval (`schedule.every`) determines how frequently the rule evaluates.
Kibana enforces a minimum interval of 5 seconds and a maximum of 365 days for duration fields (including this one). Values outside that range are rejected.
### Lookback window
The lookback window (`schedule.lookback`) determines the time range that the ES|QL query covers.
The lookback must not exceed 365 days. If the lookback is shorter than the execution interval, evaluations can miss data between runs. Use a lookback at least as long as the execution interval unless you have a deliberate reason not to.
## Activation and recovery thresholds
Activation and recovery thresholds control when alerts transition between lifecycle states. They reduce noise from short spikes and from rapid flapping between active and recovered.
These settings are only available for Alert-mode rules (`kind: alert`).
### Activation thresholds
Configure activation using count, timeframe, or both:
| Field | Description |
|---------------------|----------------------------------------------------------------------------------|
| `pending_count` | Consecutive breaches required |
| `pending_timeframe` | Minimum duration the condition must persist (shown as **Alert delay** in the UI) |
| `pending_operator` | How to combine count and timeframe (`AND` or `OR`) |
Each timeframe value must be between 5 seconds and 365 days.
### Recovery thresholds
| Field | Description |
|------------------------|----------------------------------------------------|
| `recovering_count` | Consecutive recoveries required |
| `recovering_timeframe` | Minimum duration for recovery |
| `recovering_operator` | How to combine count and timeframe (`AND` or `OR`) |
Time frame fields use the same 5 seconds to 365 days bounds as activation timeframes.
The `recovery_policy` field controls how recovery is detected, separately from how many recoveries are required. When creating a rule through the UI, `recovery_policy.type` defaults to `no_breach`, which recovers the alert episode when its active group no longer appears in the breach batch. When creating a rule through the API or Agent Builder, you can omit `recovery_policy` entirely to suppress recovery events and keep alert episodes active until closed manually. For the full field reference, go to [YAML rule schema reference](/elastic/docs-content/pull/6523/explore-analyze/alerting/kibana-alerting-experimental/rules/yaml-rule-schema-reference#recovery-policy-fields).
## No-data handling
No-data handling controls what happens when a rule executes and the base query returns no results. Proper configuration prevents false recoveries and misleading `no_data` events when data sources stop reporting.
### Behaviors
Set `no_data.behavior` to one of the following values:
| Behavior | Effect |
|---------------|-----------------------------------|
| `no_data` | Record a no-data event (default) |
| `last_status` | Carry forward the previous status |
| `recover` | Treat absence as recovery |
These behaviors apply when the base query returns zero rows. They don't help when you want to *detect* that a specific host or data source has gone silent. That requires a different query approach. See [No-data detection](/elastic/docs-content/pull/6523/explore-analyze/alerting/kibana-alerting-experimental/rules/esql-query-patterns#no-data-esql-query) in the authoring guide for an ES|QL pattern that surfaces silent sources as alert rows.
## Tags and investigation guide
Alert-mode rules support two optional metadata fields:
- **Tags**: Free-form labels for filtering and organization.
- **Investigation guide**: A runbook stored with the rule so responders have context when an alert fires.
## Evaluate rule output
Before relying on a rule in production, evaluate it against recent data by running a preview. A full evaluation surfaces how many rows the query returns, how many alert events would be generated, sample alert event documents, and a histogram of matching row counts over time.