Create an action policy for the experimental alerting system
Action policies are part of the experimental alerting system in Kibana. This page covers how to configure policy type, match conditions, grouping, frequency, and workflow destinations. Where rules define what counts as a problem, action policies define what happens when one is detected: which alert episodes generate notifications, how they batch for dispatch, and where they're routed.
Because policies are separate from rules, you can update notification behavior across many rules at once without touching detection logic, and you can route the same alert episodes differently depending on severity or source. You create and manage policies from the Action policies page, not from the rule form.
For match conditions fields, grouping modes, frequency options, and dispatch outcomes, refer to Action policy reference.
Action policies only process alert episodes from rules running in Alert mode. Signals produced by rules running in Detect mode are not eligible for action policy evaluation.
An action policy can be global or per-rule:
- Global - Global policies apply to any alert episode in the space. Use a global policy when you want to route alert episodes from multiple rules. For example, a policy matching
rule.tags: "checkout"applies to every rule with that tag. - Per-rule - Per-rule policies are scoped to a single rule. Use a per-rule policy when notification routing is specific to one rule and you don't want it to affect other rules in the space.
The policy type is set at creation and cannot be changed. If you need a different type, create a new policy.
Optional string labels you assign to a policy to categorize it or filter it on the Action policies list. Unlike rule tags, policy tags describe the policy itself rather than the alerts it matches. You can add, edit, or remove tags at any time without affecting routing behavior.
An optional KQL expression that filters which alert episodes this policy applies to. An empty match condition matches every alert episode covered by the policy's scope. For a global policy, that means all alert episodes in the space. For a per-rule policy, it means all alert episodes from the associated rule.
The match condition is the sole mechanism for scoping a policy beyond its base type. There are no separate rule type or rule ID selector fields. All scoping is done through this expression. For a global policy that should target a specific rule, use rule.id: "my-rule-id" or rule.tags: "my-tag" in the match condition.
Use match conditions to route different alert episodes to different policies, for example, one policy for severity: "critical" alert episodes routed to PagerDuty and another for lower-severity episodes routed to Slack. You can also scope by rule, such as rule.tags: "payment-service", to apply a policy only to alert episodes from a set of related rules. For available fields and examples, refer to Match conditions fields.
Notify per controls how alert episodes batch into notifications. Frequency controls how often the policy can notify for each batch.
| Notify per | What it does | Available Frequency options |
|---|---|---|
| Episode | One notification per alert episode. | - On status change - On status change + repeat at interval - Every evaluation |
| Group | Bundle alert episodes that share a field value. Specify a Group by field such as data.service.name or data.host.name. |
- At most once every… - Every evaluation |
| Digest | One notification for all matching alert episodes combined. | - At most once every… (default) - Every evaluation |
For detailed descriptions, frequency options, and examples for each mode, refer to Notify per options.
Frequency limits how often the policy can fire for a given notification group. The interval resets from the last time the policy fired, so successive notifications stay at least interval apart. Set a duration such as 1h or 30m. For available options by Notify per mode, refer to Frequency.
On status change only re-notifies when the alert episode's status changes, not when its severity changes. If an episode escalates from low to critical but the policy already matched it and the status hasn't changed, the throttle blocks re-notification.
To receive escalation notifications, either create separate policies scoped to specific severity levels, or use a time-based throttle such as At most once every 1h so the policy re-notifies after the interval regardless of severity or status changes. For examples, refer to Controlling re-notification.
One or more workflows to invoke when the policy matches. Use the search field to find and attach workflows.
- Manage action policies in experimental alerting system to view, enable, disable, or snooze the policies you create.
- Action policy reference in experimental alerting system to look up match condition fields, grouping modes, and frequency options.
- About action policies to understand how action policies evaluate and gate alert episodes.