---
title: Review action policy execution history in the experimental alerting system
description: Monitor action policy dispatch activity from the execution history. Understand dispatched, throttled, and unmatched outcomes, search and filter records, and query the event log in Discover.
url: https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8475/explore-analyze/alerting/experimental-alerting-system/action-policies/review-action-policy-execution-history
products:
- Elastic Documentation
- Kibana
applies_to:
- Elastic Cloud Serverless: Experimental
- Elastic Stack: Experimental since 9.5
---
# Review action policy execution history in the experimental alerting system
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.
Elastic Stack: Planned Elastic Cloud Serverless: Experimental To review the decisions for a single alert episode over its whole lifetime instead, use the **Policy history** tab on its details page. Refer to [Review action policy activity for this alert episode](/elastic/docs-content/pull/8475/explore-analyze/alerting/experimental-alerting-system/alerts/investigate-alert-episodes#policy-history).
Go to **Execution history** in the navigation menu or [global search](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8475/explore-analyze/find-and-organize/find-apps-and-objects), then select the **Policies** tab. Each row covers one dispatcher run for each action policy evaluated against a rule:
| Column | Description |
|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Timestamp** | When the dispatcher ran. |
| **Policy** | The action policy that was evaluated. |
| **Outcome** | Whether the dispatcher acted on the alert episode: `dispatched`, `throttled`, or `unmatched`. Definitions are in [Dispatch outcomes](#dispatch-outcomes). |
| **Rules** | The rule whose alert episodes the action policy processed. |
| **Episodes** | The number of alert episodes 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 narrow the list.
## Dispatch outcomes
After each dispatcher run, Kibana records one of the following outcomes for each action policy:
| Outcome | What it means |
|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `dispatched` | The dispatcher invoked a workflow for the alert episode. |
| `throttled` | The alert episode 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 episode. No workflow ran. |
| `dispatch_failed` | Elastic Stack: Planned Elastic Cloud Serverless: Experimental The alert episode matched an action policy and cleared the frequency gate, but invoking the workflow failed. Listed as **Failed** in the table and the outcome filter. |
### Why a dispatch failed
- Elastic Cloud Serverless: Experimental
- Elastic Stack: Planned
A `dispatch_failed` record carries a machine-readable cause in `kibana.alerting_v2.dispatcher.failure_reason`, so you can group failures without parsing the error message:
| Reason | What happened |
|----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `missing_api_key` | The action policy had no decrypted API key, so the whole action group was skipped. Rotating the key usually clears this. Refer to [Manage action policies](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8475/explore-analyze/alerting/experimental-alerting-system/action-policies/manage-action-policies). |
| `workflow_not_found` | The destination workflow ID doesn't resolve to a workflow, typically because the workflow was deleted after it was attached. |
| `workflow_disabled` | The destination workflow exists but is disabled. |
| `schedule_error` | Scheduling the workflow execution threw an error, for example from Task Manager. |
`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"`.
Alert episodes that are acknowledged, snoozed, marked inactive, or covered by a [maintenance window](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8475/explore-analyze/alerting/alerts/maintenance-windows) are excluded before the dispatcher runs and don't appear in the execution history.
## Event-log outcomes and .alert-actions action types
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` | `notified` | Policy matched, frequency cleared, workflow invoked. |
| `throttled` | `suppress` | Policy matched but frequency limit not yet cleared; no workflow invoked. |
| `unmatched` | `unmatched` | No action policy matched the alert episode; no workflow invoked. |
`.alert-actions` also records triage actions (`ack`, `unack`, `assign`, `tag`, `snooze`, `unsnooze`, `activate`, `deactivate`, `resolve`, `unresolve`) and the `fire` action type, which marks that an alert episode opened or continued. These have no event-log counterpart in this context — they aren't dispatcher outcomes. For the full field reference, refer to [Action type values](/elastic/docs-content/pull/8475/explore-analyze/alerting/experimental-alerting-system/alerts/field-reference#action-type-values).
`suppress` in `.alert-actions` means the same thing as `throttled` in the event log: the action policy matched but the frequency setting hadn't cleared yet, so no notification was sent. It's unrelated to the eligibility gate that excludes acknowledged, snoozed, or maintenance-window alert episodes before the dispatcher runs.
## Related pages
- [Manage action policies](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8475/explore-analyze/alerting/experimental-alerting-system/action-policies/manage-action-policies): Enable, disable, snooze, or rotate API keys for your action policies.
- [Action policy reference](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8475/explore-analyze/alerting/experimental-alerting-system/action-policies/action-policy-reference): Look up match condition fields, grouping modes, and frequency options.
- [About action policies](https://docs-v3-preview.elastic.dev/elastic/docs-content/pull/8475/explore-analyze/alerting/experimental-alerting-system/action-policies/about-action-policies): Understand how the dispatcher evaluates action policies against alert episodes.