---
title: Action policy reference for the experimental alerting system
description: Grouping modes, frequency options, dispatch outcomes, and match conditions field reference for action policies in the experimental alerting system.
url: https://www.elastic.co/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/action-policies/action-policy-reference
products:
- Elastic Documentation
- Kibana
applies_to:
- Elastic Cloud Serverless: Experimental
- Elastic Stack: Experimental since 9.5
---
# Action policy reference for the experimental alerting system
This page is a reference for action policy match condition fields, grouping modes, frequency options, and dispatch outcomes in the experimental alerting system. For step-by-step guidance, refer to [Create and configure an action policy](https://www.elastic.co/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/action-policies/create-configure-action-policy).
## Match conditions fields
Use the following fields in the **Match conditions** expression to filter which alert episodes an action policy applies to. Combine them with standard [KQL](https://www.elastic.co/elastic/docs-builder/docs/4300/explore-analyze/query-filter/languages/kql) operators, for example `severity: "critical" AND episode_status: "active"`.
| Field | Description | Example |
|------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------|
| `episode_id` | Unique identifier of the alert episode. | `episode_id: "ep-001"` Match a specific alert episode by ID. |
| `episode_status` | Current lifecycle status of the alert episode. One of `inactive`, `pending`, `active`, or `recovering`. | `episode_status: "active"` Match only active alert episodes. |
| `severity` | Current severity level. One of `info`, `low`, `medium`, `high`, or `critical`. Populated when the rule's ES|QL query includes a `severity` column. Not set during recovery, so a severity-scoped policy applies only to open alert episodes. Severity can change during an alert episode without reopening it. The action policy picks up the new value on the next dispatcher cycle. For how to configure severity in a rule, refer to [Severity](https://www.elastic.co/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/rules/configure-rule-severity). | `severity: "critical" OR severity: "high"` Route high-priority alert episodes to a dedicated workflow. |
| `group_hash` | Stable hash identifying the alert series the alert episode belongs to. | `group_hash: "abc123"` Match all alert episodes in a specific alert series. |
| `last_event_timestamp` | ISO 8601 timestamp of the most recent event recorded for the alert episode. | `last_event_timestamp > "2026-01-01"` Match alert episodes with activity after a specific date. |
| `data.*` | Dynamic payload fields sent by the rule. Available fields depend on the rule type and configuration. Use for rule-specific fields not covered by the standard fields in this table. | `data.host.name: "web-01"` Match alert episodes from a specific host in a host-based rule. |
To apply a policy to alert episodes from a set of rules, select those rules' tags in **Rule tags**. To learn more, refer to [Filter by rule tags](/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/action-policies/create-configure-action-policy#filter-by-rule-tags).
### Rule fields
- Elastic Cloud Serverless: Unavailable
- Elastic Stack: Planned for removal
- Elastic Stack: Experimental in 9.5
In addition to the alert episode fields, you can use the following fields in the **Match conditions** expression to select alert episodes by the rule that produced them.
| Field | Description | Example |
|-------------|-----------------------------------------------------------------|------------------------------------------------------------------------------------|
| `rule.id` | Unique identifier of the rule that generated the alert episode. | `rule.id: "rule-001"` Match alert episodes from one specific rule. |
| `rule.name` | Display name of the rule. | `rule.name: "High CPU"` Match alert episodes from rules with this display name. |
| `rule.tags` | Tags attached to the rule. | `rule.tags: "payment-service"` Match alert episodes from all rules with this tag. |
## Notify per options
Controls how the action policy batches alert episodes before invoking a workflow.
| Option | Description | When to use |
|---------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Episode | The action policy invokes a workflow once for each alert episode, independently of other alert episodes. Default selection. | You need issue-level visibility and want to handle each problem separately. |
| Group | The action policy bundles alert episodes that share the same value for a specified `data.*` field into one workflow invocation for each unique value. Each unique value forms a **notification group**. | A rule produces many related alert episodes, such as one for each service or host, and you want to reduce noise by batching them into shared notifications. |
| Digest | The action policy combines all matching alert episodes into a single workflow invocation, regardless of what they have in common. | You want a single periodic summary of everything in scope, rather than individual alert episodes. |
## Frequency
Frequency controls how often the action policy can invoke a workflow for a given alert episode or notification group. The available options depend on the **Notify per** setting. Not all options are valid for all modes.
The `.alert-actions` data stream records a throttled notification as `suppress`, not `throttled`. This is the same event described as `throttled` in the action policy execution history and event log. The two streams use different vocabulary. For the full mapping, refer to [Event-log outcomes and .alert-actions action types](/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/action-policies/review-action-policy-execution-history#outcome-vocab-mapping).
| Option | Description | When to use |
|---------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
| On status change | Invokes a workflow when the alert episode status changes, for example from active to recovering. One notification for each transition. | You only need to know when something breaks and when it's resolved. Use this when you trust your ticketing or incident workflow to track ongoing issues. |
| On status change + repeat at interval | Invokes a workflow on status change, then repeats at a regular interval while the alert episode remains in the same status. | You want status change notifications plus periodic reminders that a problem is still unresolved, in case it has been missed or pushed aside. |
| At most once every… | Limits notifications at one for each alert episode or notification group within the chosen interval, regardless of rule frequency. | You want to limit notification volume for noisy rules without missing new or ongoing issues. |
| Every evaluation | Invokes a workflow on every rule evaluation. Can be noisy. Use sparingly and only with infrequent rule schedules. | You need a full audit trail of every evaluation, or the rule runs infrequently enough that noise isn't a concern. |
### Frequency options for Episode
Available frequency options when you set **Notify per** to **Episode**.
| Option | Description | Example |
|---------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------|
| On status change | Invokes a workflow once when the alert episode opens and once when it recovers. No repeat notifications while it remains active. | A host goes down at 9:00am → one notification. Recovers at 11:00am → one notification. No notifications between them. |
| On status change + repeat at interval | Same as On status change, but also sends a reminder at a set interval while the alert episode is still active. | A host goes down at 9:00am → notification. With a 1h repeat: reminder at 10:00am, 11:00am. Recovers at 11:30am → notification. |
| At most once every… | Limits notifications at one for the alert episode within the chosen interval, regardless of severity or status changes. Use to re-notify for an alert episode that stays active without a status change. Refer to [Re-notify for persistently active alert episodes](https://www.elastic.co/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/action-policies/re-notification). | A critical alert episode stays open for 3 hours. With a 1h limit, you get a notification when it opens and again every hour it remains open. |
| Every evaluation | Invokes a workflow on every rule evaluation, regardless of status. Can be noisy on frequent rule schedules. Avoid in production. | A rule running every 5 minutes with one active alert episode produces up to 288 notifications a day. |
### Frequency options for Group
Available frequency options when you set **Notify per** to **Group**.
| Option | Description | Example |
|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------|
| At most once every… | Limits how often each notification group can invoke a workflow, regardless of how many alert episodes it contains or how often the rule runs. | 10 alert episodes share `data.host.name: "web-01"`. With a 1h limit, you get at most one notification an hour for that notification group. |
| Every evaluation | Invokes a workflow on every rule evaluation for each unique value in the group-by field. Still noisy on frequent rule schedules. | A rule running every 10 minutes with 5 unique host values produces up to 6 notifications an hour for each host. |
### Frequency options for Digest
Available frequency options when you set **Notify per** to **Digest**.
| Option | Description | Example |
|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------|
| At most once every… (default) | Limits digest delivery to at most one bundled summary within the chosen interval, regardless of how often the rule runs. | A rule running every 5 minutes with a 1h digest interval sends one bundled summary an hour containing all matching alert episodes from that period. |
| Every evaluation | Invokes a workflow on every rule run, bundling all matching alert episodes into one message. Can be noisy on frequent rule schedules. | A rule running every 30 minutes with 20 matching alert episodes produces one summary every 30 minutes containing all 20. |
## Related pages
- [Create and configure an action policy](https://www.elastic.co/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/action-policies/create-configure-action-policy): Apply these settings when configuring match conditions, grouping, and frequency.
- [About action policies](https://www.elastic.co/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/action-policies/about-action-policies): Understand the eligibility, scope, and frequency gates that run before dispatch.
- [Review action policy execution history](https://www.elastic.co/elastic/docs-builder/docs/4300/explore-analyze/alerting/experimental-alerting-system/action-policies/review-action-policy-execution-history): Check dispatcher outcomes and investigate unexpected notification behavior.