Send an alert to Zenduty when any flow fails in the company namespace

Route Kestra workflow failures straight into Zenduty so the right on-call engineer gets paged in seconds. This blueprint listens across every flow in the company namespace and, whenever an execution lands in FAILED or WARNING, fires a Zenduty event API call with the failing execution, flow, namespace, and state baked into the alert message. Centralize incident response for data pipelines, ETL jobs, infrastructure automations, and business workflows without writing custom webhooks or duplicating alerting logic in every flow.

How it works

A io.kestra.plugin.core.trigger.Flow trigger watches all executions in the Kestra instance and applies two conditions: io.kestra.plugin.core.condition.ExecutionStatus matching FAILED or WARNING, and io.kestra.plugin.core.condition.ExecutionNamespace with namespace: company and prefix: true, so it covers every sub-namespace under company. When the conditions match, the send_alert task uses io.kestra.plugin.zenduty.ZendutyExecution to POST to the Zenduty events API at https://www.zenduty.com/api/events/{integration-key}/, with the integration key pulled from {{ secret('ZENDUTY_INTEGRATION_KEY') }}. The alert message includes the triggering executionId, flowId, namespace, and final state from the upstream execution.

What you get

• Automatic Zenduty incident creation for every failed or warning execution in production
• One alerting flow that covers an entire namespace tree, no per-flow wiring
• Integration key stored as a Kestra Secret, never hardcoded
• Rich alert payload with execution ID, flow ID, namespace, and state for fast triage
• A reusable pattern you can clone for Slack, PagerDuty, Opsgenie, or email

Who it's for

• SRE and platform teams running Kestra in production
• Data engineering teams that need pager-grade alerts on pipeline failures
• On-call rotations using Zenduty for incident management
• Anyone consolidating workflow observability into a single notification channel

Why orchestrate this with Kestra

Kestra's Flow trigger is event-driven, so alerts fire the instant an execution ends, with no polling and no cron lag. Conditions let you scope alerts by namespace, status, labels, or custom expressions without touching the alerted flows. Every alert execution is itself a first-class Kestra run with logs, retries, and lineage, so you can audit which incidents were paged and when. Declarative YAML keeps the alerting policy in source control next to the flows it protects. Zenduty has no native way to subscribe to arbitrary workflow events; Kestra bridges that gap by turning execution lifecycle signals into Zenduty events.

Prerequisites

• A Kestra instance with the Zenduty plugin available
• A Zenduty account with an API integration created on a service
• Flows running under a company namespace (or rename the condition)

Secrets

• ZENDUTY_INTEGRATION_KEY: the integration key from your Zenduty API integration

Quick start

1. In Zenduty, create an API integration on the service that should receive alerts and copy the integration key.
2. Add ZENDUTY_INTEGRATION_KEY as a Kestra Secret in your environment.
3. Add this blueprint to your namespace and enable it.
4. Trigger a failing execution under company.* to confirm an incident appears in Zenduty.

How to extend

• Add a severity field by setting alertType on ZendutyExecution to critical, error, warning, or info based on the state.
• Scope alerts more tightly by adding io.kestra.plugin.core.condition.ExecutionLabels (for example, tier: production).
• Fan out to multiple channels by adding parallel io.kestra.plugin.notifications.slack.SlackIncomingWebhook or io.kestra.plugin.notifications.mail.MailSend tasks.
• Enrich the message with a direct link to the failed execution in the Kestra UI.
• Add an automatic resolve task that calls the Zenduty API when a retried execution succeeds.

Links

• Zenduty plugin docs