---
title: Create an action policy for the experimental alerting system
description: Create action policies in the experimental alerting system, configure match conditions, Notify per, Frequency, and workflow destinations.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6525/explore-analyze/alerting/experimental-alerting-system/action-policies/create-configure-action-policy
products:
- Kibana
applies_to:
- Elastic Cloud Serverless: Experimental
- Elastic Stack: Planned
---
# 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 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 action 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 action policies from the **Action policies** page, not from the rule form.
## Alert mode requirement
Action policies only apply to alert episodes from rules running in Alert mode. Rules running in Signal mode produce signals rather than alert episodes, so they aren't evaluated by action policies.
## Add tags to categorize the action policy
Tags are optional labels you assign to an action policy to categorize it or filter it in the **Action policies** list. Action policy tags describe the action policy itself, not the alert episodes it matches. You can add, edit, or remove tags at any time without affecting routing behavior.
## Filter which episodes the action policy applies to
Use a [KQL](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6525/explore-analyze/query-filter/languages/kql) expression to filter which alert episodes this action policy applies to. Leaving it empty matches every alert episode in the space. The matcher is the only scoping mechanism, there are no separate rule type or rule ID selector fields. Common patterns include scoping to a severity level (`severity: "critical"`), to a specific rule (`rule.id: "my-rule-id"`), or to rules with a shared tag (`rule.tags: "payment-service"`).
## Control how episodes batch and how often the action policy notifies
**Notify per** controls how alert episodes batch into notifications. **Frequency** controls how often the action policy can notify for each batch.
| Notify per | What it does | Available Frequency options |
|------------|-------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------|
| Episode | One notification for each 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 |
**Frequency** limits how often the action policy fires for a given notification group. The interval resets from the last time the action policy fired, so successive notifications stay at least `interval` apart. Set a duration such as `1h` or `30m`.
`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 action policy already matched it and the status hasn't changed, the throttle blocks re-notification.To receive escalation notifications, either create separate action policies scoped to specific severity levels, or use a time-based throttle such as `At most once every 1h` so the action policy re-notifies after the interval regardless of severity or status changes. For examples, refer to [Re-notify for persistently active episodes](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6525/explore-analyze/alerting/experimental-alerting-system/action-policies/re-notification).
## Select workflows to invoke
Attach one or more [workflows](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6525/explore-analyze/workflows) to define what happens when the action policy matches. If you don't have a workflow ready, you can set up a simple email or Slack notification while creating a rule instead. The system creates and links the workflow for you when you save. You can add or remove these notifications later by editing the action policy. For more complex routing or multi-step automations, build a dedicated workflow first and then attach it.
## Related pages
- [Manage action policies](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6525/explore-analyze/alerting/experimental-alerting-system/action-policies/manage-action-policies): Enable, disable, snooze, and rotate API keys after setup.
- [Action policy reference](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6525/explore-analyze/alerting/experimental-alerting-system/action-policies/action-policy-reference): Look up match condition fields, grouping modes, and frequency options.
- [About action policies](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/6525/explore-analyze/alerting/experimental-alerting-system/action-policies/about-action-policies): Understand the eligibility, match, and frequency gates that determine when workflows are invoked.