Skip to main content

​
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

1

Confirm alerts are ingested

Ensure alerts are arriving in Rootly by visiting Alerts in the Rootly UI. If no alerts are present, review your integrations on the Alerts page.
2

Create a new workflow

Navigate to Workflows → Create Workflow → Alert.
3

Choose trigger event(s)

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 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): 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 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.
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.

Incident Workflows

The most common downstream — many alert workflows declare an incident, which then fires incident workflows.

Pulse Workflows

Similar low-level event workflows, but for code-change events instead of alerts.

Alert Routing

Where alerts come from before workflows can react to them.