Loading

Event-driven triggers

Event-driven triggers let workflows react to events elsewhere in Kibana. In 9.4, the only event-driven trigger is workflows.failed, which fires when another workflow's execution fails. More event-driven triggers are planned for subsequent releases.

Warning

The event-driven trigger system, including the workflows.failed trigger, is in technical preview. The schema and semantics can change in future releases.

Fires when any workflow execution reaches the failed terminal state. Use this trigger to build handler workflows that react to failures in your production workflows, for example by paging on-call, opening a case, or logging to a dedicated index for observability.

Parameter Location Type Required Description
type top level string Yes Must be workflows.failed.
condition on KQL string No Optional KQL predicate evaluated against the event payload. The trigger fires only when the condition matches. 
triggers:
  - type: workflows.failed

Use on.condition to narrow which failed executions trigger the handler. The value is a KQL predicate evaluated against the event payload.

Fire only on failures from a specific workflow:

triggers:
  - type: workflows.failed
    on:
      condition: "event.workflow.name : 'ops--rollback-deployment'"

Ignore failures that came from another error handler:

triggers:
  - type: workflows.failed
    on:
      condition: "event.workflow.isErrorHandler : false"

Combine conditions with KQL's and to filter on multiple fields:

triggers:
  - type: workflows.failed
    on:
      condition: "event.workflow.isErrorHandler : false and event.workflow.spaceId : 'production'"

When a failed workflow triggers your handler, the handler runs with an event context that describes the failure. The payload has four groups: workflow, execution, error, and the top-level timestamp and spaceId.

Field Contains
event.spaceId The Kibana space where the failure occurred.
event.timestamp ISO timestamp of when the event fired.
event.workflow.id The failed workflow's ID.
event.workflow.name The failed workflow's name.
event.workflow.spaceId The Kibana space where the failed workflow ran.
event.workflow.isErrorHandler true if the failed workflow was itself an error handler. Use this to prevent cascading handler loops.
event.execution.id The failed execution's ID.
event.execution.startedAt ISO timestamp of when the execution started.
event.execution.failedAt ISO timestamp of when the execution failed.
event.error.message The error message.
event.error.stepId Identifier of the step where the failure occurred, when available.
event.error.stepName Name of the step where the failure occurred, when available.
event.error.stepExecutionId ID of the step execution where the failure occurred, when available.

Reference these fields with Liquid templating inside the handler:

- name: log_failure
  type: console
  with:
    message: |
      Workflow {{ event.workflow.name }} (id: {{ event.workflow.id }}) failed
      at step {{ event.error.stepName }}: {{ event.error.message }}

Example: Page on-call when a critical workflow fails

name: handle-critical-workflow-failures
description: Page on-call and open a case whenever a critical workflow fails.
enabled: true

triggers:
  - type: workflows.failed

steps:
  - name: skip_if_handler
    type: if
    condition: "event.workflow.isErrorHandler : true"
    steps:
      - name: no_op
        type: console
        with:
          message: "Skipping: the failure came from another error handler."

  - name: page_oncall
    if: "not event.workflow.isErrorHandler"
    type: pagerduty.triggerIncident
    connector-id: "platform-pagerduty"
    with:
      dedup_key: "{{ event.workflow.id }}-{{ event.execution.id }}"
      summary: "Workflow {{ event.workflow.name }} failed"
      severity: "critical"
      details:
        failed_step: "{{ event.error.stepName }}"
        error: "{{ event.error.message }}"
        workflow_id: "{{ event.workflow.id }}"
        execution_id: "{{ event.execution.id }}"

  - name: open_case
    if: "not event.workflow.isErrorHandler"
    type: cases.createCase
    with:
      title: "[Auto] Workflow failure: {{ event.workflow.name }}"
      description: |
        Step `{{ event.error.stepName }}` failed.

        Error: `{{ event.error.message }}`
      severity: "high"
      tags: ["workflow-failure", "auto-triage"]

If a handler workflow itself fails, it can re-trigger itself. Two safeguards help you avoid infinite loops:

  • Every event includes event.workflow.isErrorHandler, which is true when the failing workflow is itself a handler. Filter on this in your handler's logic to skip handling your own failures.
  • The execution engine enforces a chain-depth limit on cascading event-driven triggers as a safety net.

In practice, keep handler workflows simpler than the workflows they monitor. A handler that only logs, opens a case, and notifies is less likely to fail than the automation it's handling.