How to Send Slack Notifications When Workflows Fail

Get immediate alerts on Slack when any workflow encounters an error.

What This Integration Does

Silent failures are the worst failures. A nightly sync that quietly dies on Sunday gets noticed Monday morning when the data is already stale. This pattern wires a dedicated Slack alert workflow into every critical workflow so the on-call channel hears about failures the moment they happen, with enough detail to start debugging without opening five tabs.

The run model is per-failure. When a monitored workflow errors, it calls this alert workflow via webhook with a small JSON payload. The alert workflow formats a message, posts it to the right Slack channel, and optionally reacts/pins to make critical issues impossible to miss. The execution log captures every alert sent, which doubles as an incident audit trail.

Prerequisites

A slack connection with permission to post in the on-call and engineering channels.
Slack channel IDs for each severity level (info / warn / critical can route differently).
A naming convention for the alert payload your other workflows will send.

Step 1: Create the Alert Workflow with a Webhook Trigger

Make a new workflow called ops-workflow-failure-alert. Drop a Trigger node and set its type to Webhook. Define the expected payload shape: workflowName, errorMessage, executionId, severity, optionally environment (prod vs. staging).

Step 2: Transform - Build the Slack Payload

Add a Transform node that produces a mrkdwn message. Include the workflow name, the error, the severity, and a link back to the execution log:

{
  "text": ":rotating_light: *Workflow failure: {{ workflowName }}*\n*Environment:* {{ environment }}\n*Severity:* {{ severity }}\n*Error:* `{{ errorMessage }}`\n<https://app.spojit.com/executions/{{ executionId }}|Open execution log>",
  "channel": "{{ severityChannel }}"
}

Step 3: Condition - Severity Routing

Add a Condition node that branches on severity and sets severityChannel plus a flag for whether to mention @channel:

critical - on-call channel ID, include @channel in the text
warn - engineering channel ID, no mention
info - quiet logs channel ID, no mention

Step 4: Post to Slack

Add a Connector node pointing at the slack connector and pick the send-message tool. Pass channel and text from the Transform. The response includes the message ts, which you can use to react or pin in subsequent steps.

Step 5: React on Criticals

For critical alerts, chain a Connector node on the slack connector with the add-reaction tool, attaching rotating_light to the message timestamp. This makes truly bad alerts visually distinct from routine noise in busy channels. Optionally also call get-channel-info upstream if you want to confirm the channel still exists before posting.

Step 6: Wire Critical Workflows to Call This One

In each workflow you care about, add a final-error path that POSTs to this alert workflow's webhook URL with the structured payload. You can also configure Spojit's built-in Settings -> Notifications for email-on-error - the Slack alert workflow is the chat-channel companion that complements it.

Tips

Include the execution log link in every alert. The fastest way to triage is to look at the actual node that failed.
Use @channel only for genuine critical alerts. Overuse trains people to ignore the channel.
Keep the alert workflow itself dead simple - no retries-of-retries, no AI summarisation. It needs to work even when other things are broken.

Common Pitfalls

Letting the alert workflow alert on itself when it fails. Either route its own failures to email only, or use a separate dead-letter mechanism.
Hard-coding the Slack channel IDs across many workflows. Centralise them in this alert workflow so a channel rename only needs one edit.
Sending the entire stack trace as the message body. Truncate errorMessage to something readable and put the full trace in the execution log link.

Testing

Call the webhook directly with a sample payload for each severity. Confirm each lands in the correct channel with the correct emphasis. Then break a non-critical workflow in staging and verify the end-to-end alert. Only after both pass should you wire production-critical workflows up.