Reusable Slack Notification Subflow

Centralize all of your Slack alerting in one reusable Kestra flow. Instead of copying an incoming-webhook task and payload formatting into every pipeline, you call this single subflow and pass three inputs: the message body, a status label, and the name of the calling flow. It posts a consistently formatted Slack notification, so when you want to change the message style you edit one place and every caller updates at once. This solves the classic problem of drifting, inconsistent alerts scattered across dozens of flows.

How it works

The flow exposes three inputs: message (the body text), status (a label such as success, warning, failure, or info, defaulting to info), and source_flow (an identifier of the calling flow, defaulting to unknown). A single task, post_message, of type io.kestra.plugin.slack.notifications.SlackIncomingWebhook, sends the alert. The webhook URL is read securely from {{ secret('SLACK_WEBHOOK_URL') }}, and the JSON payload renders a one-line message in the form [STATUS] source_flow: message, uppercasing the status with the | upper filter.

What you get

• One source of truth for Slack notification formatting across every pipeline.
• Consistent, scannable alerts with a status prefix and the originating flow name.
• Secret-managed webhook URL instead of credentials pasted into many flows.
• A drop-in subflow you can call from any pipeline with three inputs.

Who it's for

• Data and platform engineers who want uniform alerting across many flows.
• Teams standardizing on a shared notification convention.
• Anyone tired of maintaining duplicated webhook tasks in every pipeline.

Why orchestrate this with Kestra

Slack incoming webhooks have no scheduler, no retry logic, and no awareness of your pipelines. Kestra wraps the webhook call in an orchestrated, declarative YAML flow that you can trigger on events, retry on transient failures, and track with full execution lineage. Because it is a subflow, callers stay simple while notification logic stays centralized and versioned. The webhook alone cannot react to pipeline state, fan out from other flows, or give you an auditable execution history; Kestra fills exactly that gap.

Prerequisites

Secrets

• SLACK_WEBHOOK_URL: the Slack incoming webhook URL used to post messages.

Quick start

1. Create a Slack incoming webhook and store its URL as the SLACK_WEBHOOK_URL secret in your Kestra namespace.
2. Add this flow to your namespace.
3. From any flow, add an io.kestra.plugin.core.flow.Subflow task calling slack-notify-subflow and pass message, status, and source_flow.
4. Run the caller and confirm the formatted message appears in your Slack channel.

How to extend

• Adjust the payload template to match your team's Slack formatting standard, including Block Kit blocks for richer layouts.
• Map status values to emoji or color attachments for at-a-glance severity.
• Swap SlackIncomingWebhook for a Slack app token task if you need threads, reactions, or file uploads.
• Pass source_flow: "{{ flow.id }}" from callers for automatic traceability.

Links

• Plugin docs: https://kestra.io/plugins/plugin-slack
• Orchestrate Slack with Kestra: https://kestra.io/orchestration/slack