Flow icon
Log icon
SlackIncomingWebhook icon

Namespace Scoped Failure Alerts to Slack with KV Enrichment

Kestra Flow trigger that watches a namespace tree for FAILED or WARNING executions, logs enriched failure context from the KV store, and alerts Slack.

Categories
Core

Give each team its own failure alerting channel instead of one global firehose. This Kestra blueprint uses a Flow trigger scoped to a namespace prefix, so every execution that ends in FAILED or WARNING anywhere under that namespace tree fires exactly one alerting run. The alert logs the failing flow, state, execution id, and outputs, enriches the message with a custom label read from the KV store, and posts a compact notification to Slack. Because the alerting logic lives in a separate flow, the monitored pipelines need zero changes.

How it works

  1. The listen trigger (io.kestra.plugin.core.trigger.Flow) subscribes to execution state changes across the instance.
  2. A dependsOn entry's states: [FAILED, WARNING] list narrows it to executions ending in those states, catching both hard failures and soft warnings.
  3. The same entry's when expression ({{ trigger.namespace startsWith 'company' }}) scopes the trigger to the company namespace tree, so other teams' failures never page this channel.
  4. The log_failure task (io.kestra.plugin.core.log.Log) records the triggering flow id, state, execution id, and outputs. It also reads {{ kv(trigger.flowId ~ '-custom-label') }} from the KV store, letting monitored flows publish extra routing context, such as a business domain or report name, that shows up in the alert.
  5. The send task (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a one line summary with the flow id, final state, and execution id to your Slack channel.

What you get

  • One alerting flow per team or environment, scoped by namespace prefix rather than instance wide.
  • Coverage of both FAILED and WARNING terminal states with a single trigger.
  • KV store enrichment so alerts carry business context the failing flow published earlier.
  • Zero changes to monitored flows, alerting is fully decoupled from pipeline logic.
  • Null safe templating with the ?? operator, so missing context never breaks the alert itself.

Who it's for

  • Platform teams running multi team Kestra instances who need per namespace alert routing.
  • SRE and on call engineers who want failure alerts in Slack without editing every flow.
  • Teams that pair this with a resubmission flow to build a full detect, notify, retry loop.

Why orchestrate this with Kestra

Failure alerting bolted into each pipeline drifts, gets copy pasted, and silently disappears when someone forks a flow. Kestra's Flow trigger inverts the dependency: this one flow observes the whole namespace tree from the outside, and conditions declaratively define what counts as alert worthy. The KV store bridges context between producers and the alerting flow without coupling them, and the alert run itself is a normal execution with logs and history you can audit.

Prerequisites

  • A Kestra instance with flows running under the namespace prefix you want to watch (adjust namespace: company to your tree).
  • A Slack incoming webhook for the destination channel.
  • Optionally, monitored flows that set a KV pair named <flowId>-custom-label for enriched alerts.

Secrets

  • SLACK_WEBHOOK: incoming webhook URL used by SlackIncomingWebhook to post the alert.

Quick start

  1. Add the SLACK_WEBHOOK secret to your Kestra namespace.
  2. Change the namespace prefix in the trigger's when expression to the one you want to monitor.
  3. Deploy the flow, then force a failure in any flow under that prefix.
  4. Confirm the alert appears in Slack and the enriched context shows in the execution logs.

How to extend

  • Add a dependsOn entry with a flowId (and namespace) to watch one specific critical flow.
  • Replace the one liner with io.kestra.plugin.slack.notifications.SlackExecution for a richer formatted message with a direct execution link.
  • Fan out to PagerDuty, email, or Microsoft Teams by adding more notification tasks after send.
  • Route different namespaces to different channels by deploying one copy of this flow per team.
  • Add a labels filter (or extend the when expression to check trigger.labels) to alert only on executions tagged as production critical.

Links

Orchestrate with Kestra
Orchestrate Slack with Kestra
Share this Blueprint
See How

New to Kestra?

Use blueprints to kickstart your first workflows.