---
title: Configure a Kibana alerting v2 rule
description: Configure {{alerting-v2}} rules: 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/5528/explore-analyze/alerting/kibana-alerting-v2/rules/configure-a-rule-v2
products:
  - Kibana
applies_to:
  - Elastic Cloud Serverless: Preview
  - Elastic Stack: Unavailable
---

# Configure a Kibana alerting v2 rule
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/5528/explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2). For notification routing, refer to [Notifications](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/5528/explore-analyze/alerting/kibana-alerting-v2/notifications-v2).
<note>
  Action policies are not configured on the rule form. You create them separately in the **Action policies** area and use KQL matchers to scope them to the episodes you want to route. The rule builder form does not link to policies.
</note>


## Rule mode

Choose a mode that matches how you want to use results:

| Mode   | Behavior                                                                                                                                                                              |
|--------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Detect | Signals only: the rule produces detections without alert lifecycle tracking or notifications.                                                                                         |
| Alert  | Lifecycle tracking and notifications: alerts move through states (pending, active, recovering, and so on), and you can attach action policies so 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/5528/explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2#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/5528/explore-analyze/alerting/kibana-alerting-v2/rules/author-rules-v2) for query patterns.
Note that rule grouping is separate from notification grouping on an action policy, which controls how 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        |
| `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.

## 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 do not 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/5528/explore-analyze/alerting/kibana-alerting-v2/rules/esql-query-patterns-v2#no-data-esql-query-v2) 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.