About action policies
An action policy is the gating layer between an alert episode and a workflow in the experimental alerting system. It decides whether and when to invoke a workflow by running the alert episode through a sequence of gates, and a workflow runs only once the episode clears every gate.
Action policies are independent of rules. A single action policy can cover alert episodes from many rules, so an action policy matching severity: "critical" applies regardless of which rule produced the alert episode. You can also update notification routing without touching any rule, and you can create rules without any action policy, which is useful for testing detection logic before wiring up notifications.
To scope an action policy to one rule, use a matcher expression, for example rule.id: "my-rule-id".
The three gates are episode eligibility, match conditions, and frequency:
- Episode eligibility - Skips episodes that are acknowledged, snoozed, or in a maintenance window. For details, refer to Reduce notification noise.
- Match conditions - Filters which alert episodes the action policy applies to. You define them using a KQL expression. An empty match condition applies to all eligible episodes in the space.
- Frequency - Controls how often the action policy can invoke its workflows for the same group of episodes, and how episodes batch before a workflow is invoked. If a workflow was already invoked within the frequency interval that you chose, the episode waits. For available options, refer to Action policy reference.
If any gate stops the episode, the workflow is not invoked for that action policy. Because each action policy evaluates alert episodes independently, an episode blocked by one action policy can still trigger a workflow through a second action policy with different conditions.
Kibana runs a background process called the dispatcher that checks for eligible alert episodes on a short interval (around 5 seconds) and evaluates action policies against them. The dispatcher runs on its own cycle, separate from the rule schedule.
For each enabled action policy that is not snoozed, the dispatcher works through the following steps:
| Step | Action |
|---|---|
| 1 | Check whether the alert episode is acknowledged, snoozed, or marked inactive. If so, stop processing it. |
| 2 | Check whether the alert episode matches the action policy's KQL. If not, stop evaluating this action policy and move to the next one. The episode continues to be evaluated by other enabled action policies. |
| 3 | Determine how matching alert episodes batch into notification groups. |
| 4 | Check whether a workflow has already been invoked for this notification group recently. If so, wait. |
| 5 | Invoke the configured workflows, on the dispatcher's next polling cycle (roughly every 5 seconds). |
A severity change can cause an action policy to match an episode for the first time and fire a notification, but it does not re-trigger an action policy that already matched the episode. For details and examples, refer to Manage severity escalation notifications.
- Create and configure an action policy: Set up match conditions, grouping, frequency, and workflow destinations.
- Manage action policies: Enable, disable, snooze, edit, or delete your action policies.
- Action policy reference: Look up match condition fields, grouping modes, and frequency options.