Review action policy execution history

In Kibana Universal Alerting, action policy execution history shows dispatcher decisions from the last 24 hours across all action policies in the space, so you can confirm notifications are dispatching as expected or investigate unexpected notification behavior.

Go to Execution history in the navigation menu or global search, then select the Policies tab. Each row covers one dispatcher run for one action policy, grouped by the rule whose alerts it processed:

Column Description
Timestamp When the dispatcher ran.
Policy The action policy that was evaluated.
Outcome Whether the dispatcher acted on the alert: dispatched, throttled, or unmatched. Definitions are in Dispatch outcomes.
Rules The rule whose alerts the action policy processed.
Alerts The number of alerts processed in this run.
Action groups The number of action groups involved.
Workflows The workflows invoked, if any.

You can search records by action policy name, rule name, or saved-object ID, and filter by outcome to view only dispatched or throttled records.

After each dispatcher run, Kibana records one of three outcomes for each action policy:

Outcome What it means
dispatched The dispatcher invoked a workflow for the alert.
throttled The alert matched an action policy but was rate-limited by the frequency setting, so no workflow ran. This is expected behavior, not an error.
unmatched No action policy matched the alert. No workflow ran.

unmatched is recorded in the event log but isn't available as an outcome filter in the execution history. To find those records, open Discover and query .kibana-event-log-* with event.provider: "alerting_v2" and event.action: "unmatched".

Note

Alerts that are acknowledged, snoozed, resolved, or covered by a maintenance window fail the eligibility check, so the dispatcher doesn't evaluate action policies for them. They don't appear in the execution history.

The dispatched, throttled, and unmatched outcomes are the event-log terms written to .kibana-event-log-*. The .alert-actions data stream records the same events using different terms. The mapping is:

Event-log outcome (event.action) .alert-actions action_type Meaning
dispatched fire and notified Policy matched, frequency cleared, workflow invoked. Kibana writes fire for each dispatched alert and notified for each workflow invocation.
throttled suppress Policy matched but frequency limit not yet cleared. No workflow invoked.
unmatched unmatched No action policy matched the alert. No workflow invoked.

.alert-actions also records triage actions (ack, unack, assign, tag, snooze, unsnooze, activate, deactivate). These have no event-log counterpart, because they aren't dispatcher outcomes. For the full field reference, refer to Action type values.

Note

The suppress action type covers more than the throttled outcome does, because the dispatcher also writes suppress for alerts that fail the eligibility check. To tell the cases apart, check the reason field. Throttled alerts have suppressed by throttled policy <policy ID>, and alerts that failed the eligibility check have ack, snooze, deactivate, or maintenance_window:<window ID>.