Set up alerts for failed workflow executions using Zenduty

Turn every failed or degraded workflow run into an actionable Zenduty incident, all from a single reusable system flow. This blueprint listens for failed and warning executions across your Kestra instance and pages the right on-call responder in Zenduty automatically, so silent pipeline failures never slip past your team. It centralizes incident alerting in one place instead of scattering notification logic across hundreds of individual flows.

How it works

1. A io.kestra.plugin.core.trigger.Flow trigger watches executions from other flows on the instance.
2. An io.kestra.plugin.core.condition.ExecutionStatus condition filters those events down to runs that ended in FAILED or WARNING state.
3. When a matching execution is detected, the send_alert task of type io.kestra.plugin.zenduty.ZendutyExecution fires an event to the Zenduty Events API at https://www.zenduty.com/api/events/{{ secret('ZENDUTY_INTEGRATION_KEY') }}/, passing the failed executionId so responders can trace the incident straight back to the run.

What you get

• Centralized failure alerting for the whole instance in one flow, not per-flow boilerplate.
• Incidents raised for both hard failures (FAILED) and soft degradations (WARNING).
• The originating executionId attached to every Zenduty event for fast root-cause tracing.
• Integration key kept out of code via Kestra Secrets.

Who it's for

• Platform and data engineering teams running shared Kestra instances.
• On-call and SRE rotations that already triage incidents through Zenduty.
• DataOps teams that need reliable, auditable failure notification.

Why orchestrate this with Kestra

Zenduty raises and routes incidents, but it has no visibility into your orchestration layer on its own. Kestra closes that gap: the event-driven Flow trigger reacts the instant any execution fails, with no polling or cron guesswork. You declare the whole pattern in one YAML file, add retries or extra notification tasks if you want, and keep full execution lineage (which flow, which run) so each Zenduty incident links back to a concrete executionId. One declarative flow covers every other flow on the instance.

Prerequisites

• A Kestra instance (Open Source or Enterprise).
• A Zenduty account with an Events API integration configured on a service.

Secrets

• ZENDUTY_INTEGRATION_KEY: the Zenduty Events API integration key used to build the events URL.

Quick start

1. Create a Zenduty service and add a Kestra (or generic API) integration to obtain an integration key.
2. Store that key as the ZENDUTY_INTEGRATION_KEY secret in Kestra.
3. Add this flow to the system namespace and enable it.
4. Trigger a flow that fails and confirm an incident appears in Zenduty.

How to extend

• Add an io.kestra.plugin.core.condition.ExecutionNamespaceCondition to scope alerts to specific namespaces.
• Chain extra tasks (Slack, email, PagerDuty) after send_alert for multi-channel escalation.
• Customize the ZendutyExecution task to set severity or enrich the incident payload.

Links

• Plugin docs: https://kestra.io/plugins/plugin-zenduty