Create an action policy

In Kibana Universal Alerting, an action policy connects alerts to the workflows that respond to them. To create one, you set which alerts the policy applies to, how those alerts batch into notifications, how often a workflow can run, and which workflows to invoke.

To start, go to Alerting → Action Policies in the Observability navigation menu, or find Action Policies using the global search field.

The policy's scope decides which alerts it applies to, and frequency decides how often the policy invokes a workflow for an alert in scope. Leave the scope empty and the policy applies to every alert in the space that passes the eligibility check. Rule events that aren't part of an alert (type: signal) stay in .rule-events, so the action policy scope doesn't include them.

To narrow the scope of an action policy, use a KQL expression.

You can also use routing tags, on their own or with an expression. If you use both, the alert's rule has to have at least one of the routing tags and the alert has to match the expression.

To apply an action policy to a rule's alerts, give the policy and the rule the same routing tag. The policy applies to alerts from every rule that has at least one of its routing tags. If you add the tag to another rule later, the policy also applies to that rule's alerts, and you don't need to edit the policy.

In Routing tags, select or enter the tags for the policy. The list recommends the routing tags that your rules already use, most-used first. You can also add a tag that no rule has yet. A policy can have up to 50 routing tags, each up to 128 characters. Matching is exact and case-sensitive, so checkout doesn't match Checkout.

Routing tags are separate from the rule's Tags field. Rule tags label and filter rules, and they don't affect which action policies apply. To add routing tags to a rule, refer to Add routing tags to a rule.

To narrow the scope further, add a match conditions expression.

Add a Match conditions KQL expression to narrow the policy to the alerts whose fields match it. For example, severity: "critical" applies the policy to critical alerts only. For the fields you can use, refer to Match conditions fields.

On a new action policy, expand Advanced matching to show Match conditions. The expression can use only the match conditions fields, so it can't select alerts by the rule's ID, name, or tags. To apply the policy to specific rules, use routing tags.

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 alerts it applies to. You can add, edit, or remove tags at any time without affecting routing behavior.

Notify per controls how alerts batch before a workflow is invoked. Frequency controls how often the action policy can invoke a workflow for each batch.

Frequency limits how often the action policy can invoke a workflow for a given alert or notification group, depending on the Notify per setting. The interval resets from the last time a workflow was invoked, so successive notifications stay at least interval apart. Set a duration such as 1h or 30m.

On status change re-notifies only when the alert's status changes, not when its severity changes. Once the action policy has invoked a workflow and the status stays the same, the throttle blocks re-notification, even if severity later escalates from low to critical.

To get a notification for the escalation, do either of the following:

• Create separate action policies scoped to specific severity levels. For examples, refer to Manage severity escalation notifications.
• Set a time-based frequency such as At most once every 1h, so the action policy invokes a workflow again after the interval regardless of severity or status changes. For examples, refer to Re-notify for persistently active alerts.

An action policy needs at least one destination. In Destination, attach the workflows that run when the action policy notifies. You can attach workflows you built earlier, create an email or Slack workflow without leaving the action policy, or do both. You can add or remove destinations later by editing the action policy.

In Workflows, search for a workflow by name and select it. Select as many as you need. Use an existing workflow for anything beyond a single message, such as opening a ticket, calling a webhook, or running several steps in order.

If the workflow doesn't exist yet, select Create a workflow to build it in the Workflows app in a new tab, then return to the action policy and select it.

If all the action policy needs to do is send an email or post a Slack message, build that workflow in the action policy itself:

1. Select Create Email workflow or Create Slack workflow.
2. Select a Connector, or select + Create new connector to add one. For Slack, also select the Channel.
3. In Parameters, write the message in YAML. An email takes to, subject, and message. A Slack message takes text.

To put alert details in the message, reference the dispatcher payload with {{inputs.payload.<field>}}, for example {{inputs.payload.policyId}}, {{inputs.payload.groupKey}}, or {{inputs.payload.alerts}}.

Kibana creates a single-step workflow for each one when you save the action policy and attaches it as a destination. These are ordinary workflows, so you can open them in Workflows afterwards to edit them or attach them to another action policy. If the action policy fails to save, Kibana deletes the workflows it created for it.

If you don't have a workflow ready, set up an email or Slack notification while you create a rule. When you save, Kibana creates the workflow and an action policy that matches that rule's alerts by rule.id.

To send a rule's alerts through an action policy that uses routing tags, add one of the policy's tags to the rule. To confirm which policies apply to a rule, check the rule's applied policies.

To link a rule to an action policy, add one of the policy's routing tags to the rule. Only rules that open alerts can have routing tags. A rule that only writes rule events (type: signal) can't, because action policies don't evaluate those events.

1. Create or edit the rule, then go to the Actions step.
2. Under Action policies, add tags in Routing tags. As you enter a tag, each suggestion shows how many action policies use it. A rule can have up to 20 routing tags, each up to 128 characters.
3. Check Applied policies. The policy appears with a tag icon ( ), and its tooltip lists the shared tag under Matching routing tags.
4. Save the rule. The link takes effect when you save.

To set routing tags in a YAML rule definition, use metadata.routing_tags.

When you create or edit a rule that opens alerts, the Actions step lists the policies that apply to those alerts under Action policies. Select a policy's name to open it for editing in a new tab.

The list also indicates why each policy applies.

• Manage action policies: Enable, disable, snooze, and rotate API keys after setup.
• Action policy reference: Look up match condition fields, grouping modes, and frequency options.
• About action policies: Understand the eligibility, scope, and frequency gates that determine when workflows are invoked.