Skip to main content

​
Overview

Incident workflows are the backbone of automation in Rootly. They run when something meaningful happens to an incident—an incident is created, severity changes, a service is added, a Slack channel is created, responders join the channel, and more. Instead of relying on responders to remember every manual step during a high-stress event, incident workflows let you encode your process once and run it consistently every time. Incident workflows are especially useful because incidents sit at the center of the response lifecycle. A single workflow can coordinate tooling across chat, paging, ticketing, documentation, and observability—so when an incident changes, everything else stays aligned automatically. Common use cases include:
  • Creating and configuring a Slack or Microsoft Teams channel when an incident begins
  • Creating tickets (Jira, Linear, ServiceNow, etc.) based on incident severity, service, or team ownership
  • Posting periodic reminders (status updates, stakeholder comms, runbook prompts) while an incident is active
  • Paging on-call responders when specific services or severities are involved
  • Generating post-incident artifacts (retrospectives, action items) when an incident resolves
  • Synchronizing incident metadata to external systems (status page timelines, docs, dashboards)
You can chain workflows across types. For example, an Alert workflow can create an incident, which then triggers Incident Created or Incident Started workflows to run the rest of your incident process.

​
How Incident Workflows Run

An incident workflow always follows the same execution model:
  1. Trigger event occurs (for example, Status Updated).
  2. Rootly evaluates run conditions (if configured).
  3. If conditions pass, Rootly executes the workflow’s actions in order.
Two behaviors are worth calling out early because they shape how you design automations:
  • Triggers are OR’d together. If you select multiple triggers, any one of them can initiate the workflow.
  • Run conditions are your guardrails. Use conditions to prevent noisy automation and ensure workflows only run when they should (for example, only for SEV0/SEV1, only for certain services, only when visibility is public, etc.).

​
Create an Incident Workflow

​
Step 1: Start a new workflow

Navigate to: Workflows → Create Workflow → Incident

​
Step 2: Choose trigger events

Trigger events define when Rootly initiates the workflow. Incident workflows support a broad set of triggers, ranging from lifecycle events (created/started) to field changes (severity/status) to channel and subscriber events. In the example below, the workflow starts when the incident status changes or when it is manually run using a Slack command:

​
Incident trigger events available

The following triggers are available for incident workflows:
  • incident_in_triage
  • incident_created
  • incident_started
  • incident_updated (catch-all update trigger)
  • title_updated
  • summary_updated
  • status_updated
  • severity_updated
  • visibility_updated
Field list changes:
  • environments_added, environments_removed, environments_updated
  • incident_types_added, incident_types_removed, incident_types_updated
  • services_added, services_removed, services_updated
  • functionalities_added, functionalities_removed, functionalities_updated
  • teams_added, teams_removed, teams_updated
  • causes_added, causes_removed, causes_updated
Timeline and post timelines:
  • timeline_updated
  • status_page_timeline_updated
Role assignment events:
  • role_assignments_added
  • role_assignments_removed
  • role_assignments_updated
Channel and membership events:
  • slack_channel_created
  • slack_channel_converted
  • microsoft_teams_channel_created
  • user_joined_slack_channel
  • user_left_slack_channel
Subscriber events:
  • subscribers_added
  • subscribers_removed
  • subscribers_updated
Manual trigger:
  • slack_command

​
Avoid overlapping triggers

Some triggers are “catch-all” events that cover other triggers.
  • incident_updated is a catch-all trigger for incident updates. If you use it, you should not also add field-specific triggers like status_updated or severity_updated in the same workflow.
  • Rootly also prevents certain redundant combinations (for example, selecting triggers that would cause duplicate initiation for the same underlying event).

​
Custom field update triggers

In addition to the built-in triggers above, incident workflows can also trigger from custom field updates. These appear in the UI as:[CustomField] <Your Field Name> UpdatedUse these when a particular custom field is a critical step in your incident process (for example, “Customer Impacted,” “Root Cause Category,” or “External Status”).

​
Step 3: Add run conditions

Run conditions define which incidents the workflow should apply to. Conditions can be based on standard incident fields (severity, status, service, environment, teams, etc.) or custom fields you’ve configured in your workspace. A strong incident workflow typically has at least one condition to avoid unnecessary automation. Examples:
  • Only run for incidents where severity is SEV0 or SEV1
  • Only run when a specific service is impacted
  • Only run when the incident is public
  • Only run when a particular team is assigned
You can learn more about how run condition operators work (including how “all of / any of / none of” behaves) in the main workflows overview: Condition Checks.

​
Step 4: Configure actions

Actions define what the workflow does once it has initiated and conditions pass. Available actions depend on the applications integrated with your Rootly workspace. For example, after connecting Jira, Jira actions become available and can be configured to create issues, set fields, assign owners, and link incidents.

​
What actions can an Incident workflow run?

Incident workflows support actions across Rootly and common incident tooling, including (not exhaustive):
  • Rootly actions (update incident fields, add timeline entries, create action items, create post-mortems, trigger other workflows)
  • Slack and Microsoft Teams actions (create/configure channels, send messages/reminders, update channel metadata, manage channel settings)
  • Paging actions (page responders through integrated on-call providers)
  • Ticketing/PM tools (Jira, Linear, ServiceNow, Zendesk, etc.)
  • Documentation and collaboration tools (Google Drive/Docs, Confluence, Notion, SharePoint, etc.)
  • Observability tools (Datadog, New Relic, Grafana, and others depending on integration availability)
Actions run in order from top to bottom. If the order matters (for example, create a Slack channel before posting a message into it), place the actions in the sequence you want them executed.

​
Failure behavior matters

By default, a single failing action halts the workflow run. If you want a workflow to continue even if an action fails (for example, “post to Slack” should not block “create a Jira ticket”), enable Skip on Failure on the actions where continuing is safe.

​
Best Practices

The best incident workflows are the ones that remain reliable under real incident pressure. These practices help you build workflows that are both powerful and predictable:
  • Start narrow, then expand. Begin with specific triggers (like severity_updated) and tight conditions. Once you trust the behavior, broaden scope if needed.
  • Use conditions as guardrails. Treat conditions as the safety layer that prevents noisy automation, especially when you use broad triggers like incident_updated.
  • Separate “setup” and “ongoing” automation. A workflow that sets up Slack/tickets is often different from a workflow that posts reminders every 30 minutes.
  • Be intentional with repeat workflows. If you use recurring reminders, make sure they stop when conditions are no longer true (for example, when status becomes Resolved).
  • Keep actions resilient. Enable Skip on Failure for non-critical actions so a partial integration outage doesn’t break your entire process.
  • Name workflows by outcome, not mechanics. Good names describe intent (for example, “Create incident channel and ticket for SEV0/SEV1”), which makes auditing easier later.
  • Validate manual Slack triggering. If you rely on Slack commands, document the command and ensure it’s memorable and unique for your team.

​
Frequently Asked Questions

Triggers define when a workflow is initiated (for example, when status_updated occurs). Run conditions define which incidents the workflow should actually apply to. In practice, triggers start the workflow, and conditions prevent it from executing when it shouldn’t.
Use incident_updated when you truly want the workflow to consider any incident update, then rely on conditions to narrow behavior. If you only care about specific changes (like severity/status/team/service changes), use the specific trigger to reduce noise and unintended runs.
Yes. Incident workflows can include custom-field update triggers that appear as [CustomField] <Field Name> Updated. This is useful when a custom field represents a process milestone or decision point.
Yes, if you include the slack_command trigger. When command feedback is enabled, Rootly posts an ephemeral confirmation message in Slack (and will indicate if the workflow is configured with a wait/delay).
By default, workflows fail fast: a failing action halts the run. To allow later actions to continue, enable Skip on Failure on the actions that should not block the rest of the workflow.
Rootly prevents overlapping triggers that would cause redundant firing (for example, selecting a catch-all update trigger together with the specific field updates it already covers). This avoids duplicate runs and keeps workflow behavior easier to predict.
Need help designing incident workflows that match your process? Contact Rootly Support at [email protected] or reach out to your onboarding/customer success representative.