Connect workflows to the experimental alerting system
Workflows are the delivery layer that defines what happens when the experimental alerting system takes an action, such as sending a message, calling a webhook, or triggering an automation. Workflows are what allow your team's incident response tools to connect with the experimental alerting system.
This page covers how action policies drive workflow invocations at runtime, the available alert episode lifecycle triggers, and when to use each pathway.
The experimental alerting system connects to workflows through two pathways.
- Action Policies - Action policies evaluate active alert episodes on a continuous schedule and invoke workflows based on match conditions and frequency settings.
- Alert episode lifecycle triggers - Workflows are invoked when a specific event occurs on an alert episode, such as when the alert episode is activated, assigned, or resolved.
Action policies evaluate alert episodes on a continuous schedule and invoke workflows when an episode meets the configured conditions. After a rule runs, the system routes alert episodes to workflows through a suppression check, match conditions, grouping, and frequency gates. For the full step-by-step evaluation sequence, refer to How action policies are evaluated.
Lifecycle triggers are a type of event-driven trigger that start a workflow immediately when a specific event occurs on an alert episode, with no scheduling or gating.
When an episode is activated, assigned, acknowledged, or snoozed, the experimental alerting system emits a named trigger event (such as alerting.episodeAssigned or alerting.episodeAcked) and any workflow attached to it runs immediately.
If you're unsure whether to use lifecycle triggers or action policies, the following table compares when each option is a good fit. Both can run different workflows simultaneously and coexist without conflict.
| Action policies | Lifecycle triggers | |
|---|---|---|
| How they run | Evaluate alert episodes on a continuous schedule | React immediately to a specific event |
| Frequency control | Apply suppression, grouping, and frequency gates | Fire exactly once per event, no gates to configure |
| Best for | Recurring notifications and escalation logic that runs as long as a problem persists | One-shot automations, such as opening a ticket when an episode is assigned or posting a message when it resolves |
- Create and configure an action policy: Start routing alert episodes to workflows.
- About action policies: Understand how action policies gate alert episodes before invoking a workflow.