How to Set Up Slack Alerts for Workflow Failures

Get immediate Slack notifications when any of your workflows fail.

What This Integration Does

When a critical workflow fails - a nightly sync, an order webhook, a payment reconciliation - you want to know in seconds, not when someone notices broken data the next morning. This pattern builds a dedicated Slack alert workflow that any other workflow can call (via webhook) when it hits an error, giving you one place to maintain the alert format, on-call channel, and severity rules.

The run model is per-failure. When an upstream workflow errors, it calls the alert workflow with details about what failed, where, and how badly. The alert workflow formats a Slack message and posts it to the on-call channel. Because the alert is its own workflow, you can tune severity routing, add reactions, or wake a paging system without touching every workflow in your org.

Prerequisites

A slack connection with permission to post in the monitoring channel.
The Slack channel ID for the on-call or monitoring channel.
An understanding of which workflows are critical enough to wire up - not everything needs to page someone.

Step 1: Create the Alert Workflow

Make a new workflow named something obvious like ops-slack-failure-alert. Drop a Trigger node and set its type to Webhook. The webhook payload should include: workflowName, errorMessage, executionId, and severity (one of info, warn, critical).

Step 2: Transform - Format the Alert

Add a Transform node that builds a Slack mrkdwn payload. Pick the emoji and channel based on severity. Example output:

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

Step 3: Condition - Severity Routing

Add a Condition node that branches on severity:

critical -> on-call channel with @channel mention
warn -> engineering channel without a mention
info -> a quieter logs channel, no mention

This keeps noisy informational alerts out of the on-call channel while still keeping the loud ones loud.

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. For critical alerts, chain a second slack step with add-reaction using rotating_light on the returned message timestamp so the alert stands out visually in the channel.

Step 5: Optional - Pin or Thread

For ongoing incidents, optionally call the slack connector with pin-message on critical alerts so they stay visible at the top of the channel until manually unpinned. If a follow-up workflow run resolves the issue, post the recovery message as a threaded reply (pass thread_ts from the original message) so the incident timeline lives in one thread.

Step 6: Wire Up the Callers

In every workflow you want to monitor, add a Condition on the final error path that calls this alert workflow via an HTTP POST to its webhook URL. Spojit's per-node retries handle transient errors, but unrecoverable failures should always end up posting to the alert workflow. You can also configure workflow-level notification rules under Settings -> Notifications for email alerts; this Slack workflow is the chat-channel companion.

Tips

Include a deep link to the execution log so on-call can investigate in one click.
Keep the alert workflow simple and reliable - it should never itself be the thing that fails silently.
Use @channel sparingly. Reserve it for true criticals, otherwise people learn to mute the channel.

Common Pitfalls

Letting the alert workflow recurse - if the alert workflow fails, it should never call itself. Use a Condition guard or a separate dead-letter mechanism.
Hard-coding the Slack channel. Use a workflow variable so dev and prod can point at different channels.
Alerting on every minor retry. The alert should fire on terminal failures, not on each retry attempt.

Testing

Trigger the alert workflow directly via its webhook with a sample payload for each severity level. Confirm the right channel receives the right format with the right mentions. Then deliberately break one non-critical workflow in a staging environment and verify the end-to-end alert.