> ## Documentation Index > Fetch the complete documentation index at: https://docs.rootly.com/llms.txt > Use this file to discover all available pages before exploring further. # Alert Workflows > Automate responses to incoming alerts by triggering workflows that declare incidents, page responders, create tickets, and notify teams based on alert data. ## Overview **Alert workflows** allow you to react automatically when external systems send alerts into Rootly. Alerts represent incoming signals from monitoring, ticketing, and paging tools such as Datadog, Grafana, PagerDuty, Jira, and others. Once ingested, those alerts become first-class objects that workflows can evaluate and act upon. Alert workflows are most commonly used to bridge the gap between raw signals and coordinated incident response. Instead of waiting for a human to interpret an alert, you can codify rules that immediately declare incidents, notify teams, or create follow-up work. Common use cases include: * Automatically declaring incidents when critical alerts are received * Paging on-call responders or notifying shared channels when alerts meet specific criteria * Creating or updating tickets and action items based on alert lifecycle changes Alert workflows only run if alerts are successfully flowing into Rootly. Before configuring workflows, verify that your alert integrations are connected and producing alerts. *** ## Supported Triggers Alert workflows support **two trigger events**: * **Alert Created** (`alert_created`)\ Fires immediately when a new alert is received in Rootly. * **Alert Status Updated** (`alert_status_updated`)\ Fires whenever an alert’s status changes (for example, from open to resolved). Unlike incident or action item workflows, alert workflows **cannot be triggered manually** via Slack command. They only run in response to alert events. *** ## Configure an Alert Workflow Ensure alerts are arriving in Rootly by visiting **Alerts** in the Rootly UI. If no alerts are present, review your integrations on the [Alerts](/alerts/alerts) page. Navigate to **Workflows → Create Workflow → Alert**. Select one or both of the available alert triggers depending on when you want the workflow to run. * Use **Alert Created** to respond immediately to new alerts * Use **Alert Status Updated** to respond to acknowledgements or resolutions *** ## Define Run Conditions Alert workflows can evaluate multiple properties of an alert. Conditions are optional but strongly recommended to avoid over-triggering. ### Source The **source** condition matches on the **source type** of the integration that generated the alert — values like `datadog`, `pagerduty`, `generic_webhook`, `aws_cloudwatch`, and so on. Use this to scope a workflow to alerts coming from a specific kind of integration. **The source condition takes a source type, not an alert source UUID.** If you paste in a specific source ID (for example, `a410cb8d-2851-447b-bba9-076b20d664bc`), the condition will never match incoming alerts and the workflow will silently never run. To scope a workflow to a specific alert source *instance* rather than all sources of a given type, combine the source-type condition with a `source_name` label condition (see [Scoping to a specific source instance](#scoping-to-a-specific-source-instance) below). *** ### Scoping To A Specific Source Instance If you have multiple alert sources of the same type — for example, two Generic Webhook sources named "Harbor Image Scan" and "Deployments" — the Source condition alone can't tell them apart. Every alert ingested from a generic-webhook source is automatically tagged with a **`source_name`** label whose value is the alert source's name parameterized (lowercased, spaces and other non-alphanumeric characters replaced with hyphens): | Alert source name | Auto-added label | | ------------------------ | ---------------------------------- | | `Harbor Image Scan (c1)` | `source_name:harbor-image-scan-c1` | | `Deployments` | `source_name:deployments` | | `Prod Kafka Consumer` | `source_name:prod-kafka-consumer` | Combine a source-type condition with a `source_name` label condition (using **contains any of**) to route alerts from a specific source instance to a specific workflow. The source-type condition keeps the workflow scoped to webhook traffic only; the `source_name` label condition selects the exact source. *** ### Status Alerts move through lifecycle states. Valid values include: * `open` * `triggered` * `acknowledged` * `resolved` Status conditions are commonly used with the **Alert Status Updated** trigger to run workflows only when alerts are resolved or acknowledged. *** ### Labels Alerts include a set of labels derived from the source system. Labels are stored as an **array of values**. You can condition on labels using operators such as “contains any of” or “contains all of.” *** ### Payload Each alert includes a **JSON payload** containing source-specific data. Payload conditions allow advanced filtering using: * **JSONPath** to extract values from the payload * Optional **regular expressions** to match extracted values For example, you can match alerts where `$.data.type` equals `incident`, regardless of case. Payload conditions are powerful but should be tested carefully. A malformed JSONPath or overly broad regex can cause workflows to misfire. *** ## Configure Actions Alert workflows support a wide range of actions. Available actions depend on which integrations are connected to your workspace. Common actions include: * Declaring incidents in Rootly * Paging on-call responders * Sending Slack or Microsoft Teams messages * Creating or updating tickets in Jira or other systems * Creating action items for follow-up work ### Downstream Workflow Cascades If an alert workflow declares an incident, that will immediately trigger **incident workflows** that listen for “Incident Created” or related events. When testing alert workflows, it is strongly recommended to: * Temporarily disable incident workflows, or * Add restrictive run conditions to prevent unintended cascades. *** ## Best Practices Alert workflows are most effective when they are precise and conservative. * **Start narrow.** Use source, status, and payload conditions to target only the alerts that truly require automation. * **Avoid duplicate incident creation.** Ensure alert grouping or deduplication is considered when declaring incidents from alerts. * **Test in isolation.** Disable downstream workflows during initial testing to avoid accidental paging or ticket creation. * **Use status-based triggers intentionally.** “Alert Created” is best for immediate response, while “Alert Status Updated” is better for follow-up automation. * **Document your logic.** Complex payload conditions should be explained in the workflow description for future maintainers. *** ## Frequently Asked Questions No. Alert workflows only run in response to alert events. Manual Slack commands are not supported for this workflow type. Yes. Declaring incidents is a common use case. Be aware that doing so may trigger incident workflows downstream. Check that alerts are flowing into Rootly, confirm the trigger event fired, and review run conditions — especially payload and label filters. A common silent failure is using an **alert source UUID** in the Source condition instead of the source **type** (`datadog`, `generic_webhook`, etc.). See [Source](#source) for the correct values. Yes. Use the source condition to filter by integration type, plus payload or labels to match severity or priority fields provided by the source system. To scope to a specific source instance rather than all sources of a given type, see [Scoping to a specific source instance](#scoping-to-a-specific-source-instance). No. Advanced Alert Routing and `alert_created` workflows are independent and run alongside each other. Enabling Advanced Alert Routing does not disable, supersede, or otherwise gate alert workflows — you do not need an Alert Route configured for an `alert_created` workflow to fire. If a workflow isn't firing on real alerts, the cause is almost always a run condition that doesn't match (see the Source condition FAQ above), not Advanced Alert Routing. *** Need help designing safe and effective alert automation? Contact your Rootly onboarding representative or email **[support@rootly.com](mailto:support@rootly.com)**. *** ## Related Pages The most common downstream — many alert workflows declare an incident, which then fires incident workflows. Similar low-level event workflows, but for code-change events instead of alerts. Where alerts come from before workflows can react to them.