Workflows are ordered event rules for your workspace. Every alert is checked against them before it opens an incident or joins one — monitor failures, Events API triggers, email alerts and incidents people open by hand all go through the same rules, so the routing decision is the same whatever the source.
Workflows are on the Business plan (see Pricing). On other plans your rules are kept but not applied.
Find them under On-call → Workflows. Each rule has conditions, actions and an on/off switch; drag rules (or use the arrows) to change their order.
How rules run
- Enabled rules are checked top to bottom against the alert as it arrived.
- A rule matches when all of its conditions hold — or any, if you choose. A rule with no conditions matches every alert.
- A matching rule’s actions apply, then the next rule is checked. Severity, escalation policy and paging: the last matching rule wins. Title templates build on each other. Responders, notifications and tags add up.
- Stop processing later rules ends the run after that rule. Suppress ends it too, and opens nothing.
Then the alert is deduplicated and grouped as usual. An alert that joins an incident that’s already open keeps a record of the rules it matched, but doesn’t change that incident.
Conditions
| Condition | Matches on |
|---|---|
| Source | Monitor, Events API, email or manual. |
| Integration | The Events API or email integration that received the alert. |
| Monitor / monitor tag | The monitors behind the alert, or any of their tags. |
| Environment | production, staging and your other environments. |
| Incoming severity | The severity the alert arrived with, before any rule changed it. |
| Title / summary | Contains, doesn’t contain, is, starts with, matches a glob (*disk*, db-?) or a regular expression. |
| Payload field | A dotted path into the alert: for the Events API the event payload — custom_details.region, component, group, class, source; for email from, subject, text; for monitors status. Is, isn’t, contains, exists, doesn’t exist. |
| Time of day | Inside or outside a window on chosen days, in a time zone — e.g. outside Mon–Fri 09:00–17:00 America/Chicago. |
Text comparisons ignore case. Time windows follow the wall clock in their zone, so daylight-saving changes need no edits; a window that ends before it starts (18:00–08:00) runs overnight and belongs to the day it starts on.
Regular expressions run on a linear-time matcher, so no pattern can slow down alert intake. They support the usual syntax — classes, \d \w \s \b, groups, alternation, * + ? {n,m}, ^ $ — but not lookarounds or backreferences, and are limited to 200 characters. Unsupported patterns are rejected when you save.
Actions
| Action | What it does |
|---|---|
| Set severity | SEV-1 to SEV-4. SEV-3 and SEV-4 page with low urgency. |
| Route to escalation policy | Pages this policy instead of the monitor’s or integration’s. |
| Page or open quietly | Quietly: the incident opens and nobody is paged until someone escalates it. |
| Suppress | Records the alert and opens no incident. Never applies to incidents a person opens. |
| Rewrite title | A template: [{environment}] {title}. Also {severity}, {source}, {service}, {summary} and payload fields like {payload.custom_details.region}. |
| Add responders | People join the incident and are paged (unless it opened quietly). |
| Notify Slack / webhook | Posts the new incident to those integrations. |
| Add tags | Shown on the incident. |
| Add a note | A note on the timeline — a runbook link, a first step. Takes the same placeholders as titles. |
| Stop processing later rules | Later rules aren’t checked for this alert. |
Every rule that shapes an incident leaves a line on its timeline — Rule “After-hours DB” routed to Data on-call, set SEV-3 — and each rule shows how many alerts it has matched.
To keep a Slack channel or webhook for routed incidents only, open it under Integrations and turn on Only incidents routed here by a workflow rule. It then hears only about incidents a rule (or an escalation step) sends to it, and their follow-ups.
Test with a sample alert
The rule editor has a Test with a sample alert panel: pick a source, title, severity, integration or monitor, paste an event payload and choose when it arrives. Pulseback runs your saved rules, with the one you’re editing in its place, and shows which matched, which conditions held, the timeline lines they would write, and the incident that would open — title, severity, the policy that would be paged and why, responders, tags. Nothing is saved or paged.
Examples
After-hours database alerts go to the data team at SEV-3. Conditions (all): monitor tag is database; time outside Mon–Fri 09:00–17:00. Actions: route to Data on-call, set SEV-3.
Canary checks never page. Condition: title matches glob *canary*. Actions: suppress, stop.
Datadog warnings open quietly, prefixed with the environment. Conditions (all): integration is Datadog; incoming severity is SEV-3 or SEV-4. Actions: open quietly, rewrite title [{environment}] {title}.
EU database events also go to the EU channel. Condition: payload custom_details.region is eu-west. Actions: notify #db-eu, add tags eu.
API
Rules are part of the REST API: GET/POST /api/workspaces/:wid/workflows, PATCH/DELETE …/workflows/:id, POST …/workflows/:id/enable and /disable, POST …/workflows/reorder with every rule id in the new order, and POST …/workflows/test for a dry run.