Alert triggers

Alert triggers run workflows automatically when detection or alerting rules generate an alert. Use alert triggers for alert enrichment, automated incident response, case creation, or notification routing.

Alert-triggered workflows run with the privileges of the user who last saved the rule. For details, refer to Workflow authorization.

When a rule generates an alert that triggers your workflow, the trigger provides rich context data to the workflow through the event field.

Alert triggers are different from alert lifecycle triggers. An alert trigger (type: alert) runs a workflow when a detection rule or a Kibana Classic Alerting rule generates an alert, and only when you add the workflow to that rule as an action. Alert lifecycle triggers are event-driven triggers that run automatically when a user acts on an alert in Kibana Universal Alerting, such as assigning or acknowledging it, with no rule action to configure.

Warning

Declaring type: alert on a workflow isn't enough to run the workflow when alerts fire. You also have to attach the workflow to the rule's Actions using a Run Workflow action. Without the attachment, the rule fires alerts but the workflow is never invoked. This is the single most common setup mistake.

Schema

Parameter	Type	Required	Description
`type`	string	Yes	Must be `alert`.

That's the entire trigger schema. There's no with block on an alert trigger: rule targeting happens in the alerting rule's Actions configuration, not in the workflow.

triggers:
  - type: alert

Setup

To set up an alert trigger, follow these steps:

Define an alert trigger

Create a workflow with an alert trigger:

name: Security Alert Response
description: Enriches and triages security alerts
enabled: true
triggers:
  - type: alert
steps:
  ....

Configure the alert rule

After creating your workflow, configure your alert rule to trigger it.
Alerting rules (Stack and Observability)
1. Go to Rules in Stack Management or use the global search field.
2. Find or create the alerting rule you want to trigger the workflow.
3. In the rule settings, under Actions, select Add action.
4. Select Workflows.
5. Select your workflow from the dropdown or create a new one. You can only select enabled workflows.
6. Under Action frequency, choose whether to run separate workflows for each generated alert.
7. (Optional) Add multiple workflows by selecting Add action again.
8. Create or save the rule.
Security detection rules
1. Go to Detection rules (SIEM) in the navigation menu or use the global search field.
2. Find or create the detection rule you want to trigger the workflow.
3. In the rule settings, under Actions, select Workflows.
4. Select your workflow from the dropdown or create a new one. You can only select enabled workflows.
5. Under Action frequency, choose whether to run separate workflows for each generated alert.
6. (Optional) Add multiple workflows by selecting Add action.
7. Create or save the rule.

When the configured rule generates an alert, your workflow automatically executes with the alert context.

Alert event payload

When an attached rule fires, the workflow runs and receives the alert payload through the event context variable:

`event.*` field	Contains
`event.alerts`	Array of alert documents produced by the rule.
`event.rule`	Metadata about the rule that fired, including `id`, `name`, `tags`, and `type`.
`event.spaceId`	The Kibana space the rule belongs to.
`event.params.*`	Any params configured on the rule's Run Workflow action.

Reference these fields with Liquid templating in workflow steps:

- name: log
  type: console
  with:
    message: |
      Got {{ event.alerts | size }} alerts from rule "{{ event.rule.name }}".
      First host: {{ event.alerts[0].host.name }}

The shape of an individual alert document inside event.alerts depends on the rule type (detection rule, alerting rule, or ES|QL rule) and the source data the rule runs against. Common fields include _id, _index, host.name, user.name, kibana.alert.severity, kibana.alert.risk_score, and kibana.alert.start.

Alert states

When you attach a workflow to an alerting rule, you can choose which alert states trigger it:

State	Meaning	Default
`new`	First time this alert has fired.	On
`ongoing`	Alert is continuing from a previous check.	Off
`recovered`	Alert has cleared and returned to normal.	Off

Security detection rules produce only new alerts, so the state checkboxes are hidden for them. Observability rules that track ongoing conditions benefit from separate workflows per state. For example, a first-response workflow on new and a recovery-notification workflow on recovered.