Workflow Alerts
An alert rule tells you when a run of a workflow ends a certain way: it failed, timed out, completed, took too long, had a node fail, failed several times in a row, or could not be submitted. Rules work for draft runs (a Run from the builder) and deployed runs alike.
Where to find them
Open Workflow Monitor, choose the workflow, and click Alerts at the top right of its Execution History. The page lists the workflow's alert rules and, below them, every alert they sent.
Creating a rule
Click New Alert Rule and fill in:
| Setting | What it does |
|---|---|
| Name | How the rule appears in the list and in each alert |
| When | The condition (see below) and, for some, its setting |
| Alert me by | One or more channels: In-app notification (your bell, no setup), Email (the addresses you list, or your own), a Slack incoming webhook URL, or a Webhook URL that receives the alert as JSON |
| At most one alert per interval | Throttling: once the rule fires, it stays quiet for the minutes you set |
| When | Fires when |
|---|---|
| A run failed | A run ends failed or with an error |
| A run timed out | A run ends because it timed out |
| A run completed | A run runs to its end: completed, completed with gaps, or partial success |
| A run took too long | A run that ended (completed or failed) took at least the seconds you set |
| A node failed | A node of the run failed; list node types (for example code, http-request) to hear only about those |
| Failed several times in a row | The workflow has failed the number of times you set since its last run that ran to its end |
| Runs waiting in the Dead Letter Queue | A run could not be submitted, and the Dead Letter Queue now holds at least the number you set of the workflow's runs unresolved |
A stopped or cancelled run fires no alert: someone ended it on purpose.
Use Pause / Resume to switch a rule off and on, and the trash button to delete it (its alerts stay in the list).
What you receive
Each alert says which workflow and rule it is about, the run, its status and duration, and its error when it failed:
- In-app: a notification in your bell, linking to the workflow.
- Email: from the platform's mail server; if the platform has none configured, the alert records that it was not sent.
- Slack: a message to the incoming webhook's channel.
- Webhook: a
POSTof{"alert": {ruleName, condition, message, workflowId, workflowName, executionId, details, triggeredAt}}. Only headers startingX-Custom-,X-Webhook-orX-Strongly-(andContent-Type,Accept) are sent. A Slack or webhook URL must reach the internet; one that points inside the platform's network is refused when you save the rule.
Alerts sent lists every alert with the run it was about and each channel's outcome: sent, or why it was not.
Who receives what
A rule is yours: only you see it and only you are alerted. It fires only while you may use the workflow; if the workflow stops being shared with you, your rule stays quiet.
How it works
When a run ends, the workflow-controller marks its end for announcement once the run is finalized. The platform then fires the workflow's alert rules and emits the workflow.completed or workflow.failed event, which starts any deployed workflow whose Event trigger listens for it. A run's end is announced once.
API, SDK and STAN
Rules and alerts are also at /api/v1/workflow-alerts (see Workflow Alerts API), in the Python SDK as client.workflows.create_alert_rule() and related methods, and STAN can create them for you ("tell me in Strongly when the invoice workflow fails").