Kibana alerting v2 notifications
After a rule produces alert episodes, action policies decide what to do about them: who gets notified, how often, and through which channel.
This page explains how action policies work. For creating and configuring them step by step, refer to Create and configure an action policy.
An action policy is a saved object in your space that controls notification routing. It's not attached to a rule. It's global within the space, so when an episode is produced, the system evaluates all enabled policies in the space that are not snoozed and decides which ones apply.
Each policy has four controls:
| Control | What it does |
|---|---|
| Matcher (optional KQL) | Filters which episodes this policy applies to. An empty matcher matches all episodes in the space. |
| Dispatch per (grouping) | Controls how episodes batch into notifications: one per episode, one per defined group, or one digest for all. |
| Frequency (throttling) | Controls how often the policy can notify for the same group. |
| Destinations | One or more workflows to invoke when all conditions are met. |
Action policies don't reference rules directly. You scope a policy using KQL over episode and rule fields, for example rule.labels: "checkout" or data.severity: "critical". A policy applies to every matching episode in the space, from any rule.
Multiple policies can match the same episode, and each runs independently. There's no precedence or merging between them. If no policy matches an episode, no notification is sent. This is intentional.
When an episode is eligible for dispatch, the system processes each enabled policy that is not snoozed, in order:
- Suppression: Is the episode acknowledged, snoozed, or deactivated? If so, skip dispatch.
- Matcher: Does the episode match the policy's KQL? If not, skip this policy.
- Grouping: How should matching episodes batch into notification groups?
- Throttle: Has a notification already gone out for this group recently? If so, wait.
- Destinations: Send to the policy's workflow destinations.
The dispatcher runs on a short interval (around 10 seconds). Notifications don't arrive on the exact rule schedule. They follow the dispatcher's own cycle.
Each notification attempt results in one of the following outcomes.
| Outcome | What it means |
|---|---|
dispatched |
A notification was sent. |
throttled |
Dispatch was suppressed due to throttle timing. |
suppressed |
The episode was suppressed before dispatch (acknowledged, snoozed, or deactivated). |
unmatched |
No policy matched this episode; no workflow ran. |
error |
Processing failed. Check Kibana logs. |
You can query these outcomes in Discover through the .alert-actions data stream.
Rules don't own policies. A rule can't say "notify team X when it fires." Instead, team X creates an action policy that uses a KQL matcher to pick up matching episodes.
This design means:
- One policy can cover episodes from many rules.
- You can update routing without touching any rule.
- Rules can be created without any notification policy, which is useful for testing.
When you're ready to route notifications, go to Create and configure an action policy.