Pulse Workflows

​

Overview

Pulse workflows run automatically when Rootly receives a pulse. Pulses are code-change events (for example, pushes, merges, and deployments) streamed into Rootly from supported source control and CI/CD integrations such as GitHub and GitLab. Pulse workflows are designed for teams that want to connect delivery signals to operational response. Instead of treating deployments as “background noise,” you can use pulses to proactively notify responders, create artifacts for visibility, and even pre-declare incidents when the change itself represents elevated risk. Pulse workflows are particularly useful for:

• Pre-declaring incidents when risky changes ship, so responders have a shared coordination space ready if impact appears
• Broadcasting deployments into shared channels (for example, release, infrastructure, or product channels) with consistent formatting and context
• Creating follow-up work automatically when a pulse matches a high-risk pattern (specific repo, branch, environment, or payload value)

---

​

Supported Trigger

Pulse workflows support one trigger event:

• Pulse Created (pulse_created)
  Fires immediately when a new pulse is received in Rootly.

---

​

Configure a Pulse Workflow

​

Step 1: Confirm pulses are ingested

To use a pulse workflow, you must first ensure Rootly is receiving pulses. Navigate to Configuration → Pulses to verify recent pulse events exist. If you do not see pulses, review your integration configuration on the Pulses page.

---

​

Step 2: Create a new workflow

Navigate to: Workflows → Create Workflow → Pulse

---

​

Step 3: Select the trigger event

Because pulse workflows only support one trigger, choose Pulse Created. This causes the workflow to initiate as soon as the pulse arrives in Rootly.

---

​

Define Run Conditions

Pulse workflows can be filtered using three pulse properties. These conditions let you target only the pulses you care about (for example, production deploys, changes from a specific repository, or events with a specific payload field).

​

Source

The source represents where the pulse originated from (for example, GitHub or GitLab). Source conditions can optionally use regular expressions, which is helpful when your source naming varies by integration or workspace. You can find the source on the main Pulses page:

---

​

Label

Each pulse includes a set of labels derived from the source system. Labels are stored as an array of values, and you can filter on them using operators such as “contains any of” or “contains all of.” Label conditions can also optionally use regular expressions. You can find labels on the pulse details page: Configuration → Pulses → select a pulse

---

​

Payload

Each pulse includes a JSON payload containing source-specific data (commit metadata, repository identifiers, environment details, and other fields depending on the integration). Payload filtering supports:

• JSONPath (configured as the payload query) to extract the value you want to evaluate from the pulse JSON
• Optional regular expression matching against the extracted value

For example, you can extract a specific field like an environment ID or branch name and require an exact match, partial match, or regex match. You can find payload data on the pulse details page: Configuration → Pulses → select a pulse

---

​

Configure Actions

Pulse workflows do not have a fixed action set. The actions available to your workflow depend on which integrations are connected in your Rootly workspace. Common actions teams use with pulse workflows include:

• Declaring or updating an incident in Rootly
• Sending Slack or Microsoft Teams messages with structured deployment context
• Creating or updating follow-up work items (tickets, action items, tasks) when a pulse matches a risk condition
• Triggering additional workflows (for example, handing off from a “deployment detected” workflow into a more complex automation chain)

---

​

Best Practices

Pulse workflows are most effective when they are scoped intentionally and validated with real examples.

• Start narrow and expand. Begin with conditions that target a specific repository, branch, or environment before broadening to all pulses.
• Prefer labels and payload for precision. Source-only filters are rarely enough; labels and payload fields usually provide the reliable signal you need.
• Use pre-declared incidents sparingly. Pre-declare incidents only when the change itself represents elevated risk, otherwise you may create alert fatigue through too many “false starts.”
• Test with recent pulses. Always validate your JSONPath and label logic against real pulse examples visible in the UI.
• Document intent in the workflow description. Pulse workflows often encode operational policy (what constitutes a risky change). Make that intent explicit so future maintainers do not guess.

---

​

Frequently Asked Questions

---

Need help designing safe pulse automation? Contact your Rootly onboarding representative or email [email protected].