Kibana alerting v2 rule settings

Rule settings control how a Kibana alerting v2 rule evaluates data, manages alert lifecycle, and routes notifications. This page provides an overview of all configurable settings. Refer to the linked pages for detailed guidance on each.

The schedule and lookback settings control how often the rule runs and how far back it looks when evaluating data.

• Execution interval (schedule.every) — how often the rule evaluates, for example every 1 minute or 5 minutes.
• Lookback window (schedule.lookback) — the time range for the ES|QL query, for example the last 15 minutes of data.

Activation and recovery thresholds prevent transient conditions from creating actionable alerts and prevent rapid toggling between active and recovered states.

• Activation threshold — consecutive breaches or minimum duration before pending → active.
• Recovery threshold — consecutive recoveries or minimum duration before recovering → inactive.

No-data handling controls what happens when the rule query returns no results:

• no_data — record a no-data event.
• last_status — carry forward the previous status.
• recover — treat as recovery.

Grouping splits alert event generation by one or more fields. Each unique combination produces its own alert series with independent lifecycle tracking.

Notification policies are standalone entities that control how alerts reach people and systems. Link one or more policies to a rule to enable matching, grouping, throttling, and routing to workflow destinations.

Workflows are automated sequences of tasks. Rules can link to workflows directly for rule-triggered actions, or workflows can be referenced as destinations in notification policies.

These settings are configured in the rule form or YAML: