Type to search.

Rule event and alert action field reference

Serverless

Elastic Cloud Serverless projects are autoscaled environments, fully managed by Elastic and available on Elastic Cloud.

Availability

  • Generally available

    This functionality is generally available and ready for production usage.

Serverless interfaces and procedures might differ from classic Elastic Stack deployments.

Stack Planned

The Elastic Stack includes Elastic's core products such as Elasticsearch, Kibana, Logstash, and Beats.

Availability

  • Planned

    We plan to add this functionality in a future Elastic Stack update. Subject to changes.

Unless stated otherwise on the page, this functionality is available when your Elastic Stack is deployed on Elastic Cloud Hosted, Elastic Cloud Enterprise, Elastic Cloud on Kubernetes, and self-managed environments.

This documentation corresponds to the latest patch available for each minor version. If you're not using the latest patch, check the release notes for changes.

Kibana Universal Alerting writes rule output and triage data to two data streams:

  • .rule-events field schema: Fields written on each rule event. Events with type: signal and events that belong to an alert (type: alert) share this stream and most fields. The episode.* fields appear only on events with type: alert.
  • .alert-actions field schema: Fields written when a user or the system acts on an alert, including all action_type values.

Use these schemas when writing ES|QL queries in Discover, interpreting alert UI state, or aligning API payloads with stored data.

Kibana writes one rule event per matching row, per run, to .rule-events. When Kibana tracks an alert, it can also write recovered and no_data events. Fields use dot-notation for nested objects. The episode.* fields are only present on events that belong to an alert (type: alert).

The signal and alert columns show which type values include the field.

Field Type signal alert Description
@timestamp date ✅ ✅ When Kibana wrote this document.
scheduled_timestamp date ✅ ✅ The scheduled start time for this rule run.
rule.id keyword ✅ ✅ ID of the rule that produced this event.
rule.version long ✅ ✅ Version of the rule at evaluation time.
group_hash keyword ✅ ✅ Identifies the series this event belongs to.
status keyword ✅ ✅ Outcome of a single evaluation row, independent of alert lifecycle. Events with type: signal are always breached. Events with type: alert can be breached, recovered, or no_data.
type keyword ✅ ✅ Event kind: signal (not part of an alert) or alert (part of an alert).
severity keyword ✅ ✅ Optional. Set on breached events when the query emits a recognized value. Can be one of the following: info, low, medium, high, critical. Not set on recovered or no_data events.
data flattened ✅ ✅ Rule-defined payload from the source query.
source keyword ✅ ✅ Source that produced the event.
space_id keyword ✅ ✅ Kibana space where the rule lives.
episode.id keyword ❌ ✅ ID of the alert this event belongs to. Events that share this value are the same alert.
episode.status keyword ❌ ✅ Lifecycle state of the alert at this evaluation. Can be one of the following: inactive, pending, active, recovering.
episode.status_count long ❌ ✅ Count of consecutive evaluations in the current episode.status. Set only for pending or recovering.

When a user or the system records an action on an alert, Kibana writes a document to .alert-actions. Use this stream for triage history, operational metrics such as mean time to acknowledge (MTTA), and auditing. Events with type: signal never produce .alert-actions rows.

Field Type Description
@timestamp date When Kibana wrote this action document.
alert_id keyword ID of the alert.
alert_status keyword Lifecycle state of the alert at the time of this action. Can be one of the following: inactive, pending, active, recovering.
rule_id keyword ID of the rule that owns the alert.
group_hash keyword Identifies the series the alert belongs to.
action_type keyword Identifies what happened and who initiated it. For more information, refer to Action type values.
actor keyword User who performed the action. Null for system-written action types.
assignee_uid keyword Target user for assign actions.
last_series_event_timestamp date Timestamp of the most recent event in the series, as of when this action occurred.
expiry date When the snooze expires. Only set for snooze actions.
action_group_id keyword The action group the alert belonged to at the time of this action.
source keyword Source that triggered the action.
tags keyword[] Tag values written by tag actions.
reason text Reason provided for activate or deactivate actions. For system-written types, it records why the dispatcher wrote the document, such as the policy that dispatched or throttled the alert.
space_id keyword Kibana space where the alert lives.

Every .alert-actions document has an action_type that identifies what happened and who initiated it. Users trigger the user-written types through the API or UI. The dispatcher writes the system-written types when it evaluates action policies. System-written documents identify the alert's series with group_hash and might not include the alert ID.

Value Written by What happened
ack user Acknowledged the alert
unack user Removed the acknowledgment
assign user Assigned to a user (assignee_uid)
tag user Added tags
snooze user Snoozed until expiry
unsnooze user Removed the snooze
activate user Set the alert to active and held it there until a deactivate action. Unresolve in the UI writes this type.
deactivate user Closed the alert. Resolve in the UI writes this type.
fire system An action policy dispatched the alert to its workflow. The reason field names the policy.
notified system Workflow invoked. One document per invocation, which can cover several alerts.
suppress system No workflow ran for the alert, either because the alert was acknowledged, snoozed, resolved, or in a maintenance window, or because an action policy's frequency limit hadn't cleared. The reason field says which.
unmatched system No action policy matched the alert