Log icon
SlackIncomingWebhook icon
Flow icon
ExecutionStatus icon
ExecutionNamespace 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. An io.kestra.plugin.core.condition.ExecutionStatus condition narrows it to executions ending in FAILED or WARNING, catching both hard failures and soft warnings.
  3. An io.kestra.plugin.core.condition.ExecutionNamespace condition with prefix: true 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 ExecutionNamespace condition to the namespace prefix 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 an io.kestra.plugin.core.condition.ExecutionFlow condition 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 an ExecutionLabels condition to alert only on executions tagged as production critical.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.