Send an alert to Zenduty when a flow fails

Turn every Kestra flow failure into a Zenduty incident automatically. This blueprint demonstrates the errors block pattern: a deliberately failing shell task triggers a io.kestra.plugin.zenduty.ZendutyAlert task that posts a fully structured event to the Zenduty Events API, complete with severity, summary, entity id, and a deep link back to the alert. It is the canonical example of attaching on-call alerting to any orchestrated pipeline without writing custom HTTP clients, retry loops, or shell wrappers around curl.

How it works

• The fail task uses io.kestra.plugin.scripts.shell.Commands and runs exit 1 to simulate a real production failure.
• When the task fails, Kestra evaluates the flow level errors block.
• The alert_on_failure error handler calls io.kestra.plugin.zenduty.ZendutyAlert, sending a JSON payload to https://www.zenduty.com/api/events/{{ secret('ZENDUTY_INTEGRATION_KEY') }}/.
• The payload sets alert_type, message, summary, entity_id, a nested payload with status, severity, and project, and a urls array that surfaces a clickable link inside the Zenduty incident.
• Zenduty applies routing, escalation policies, and on-call schedules from there.

What you get

• A working pattern you can paste into any flow to wire up paging on failure.
• A real Zenduty API call structure, with required fields (message, summary) and optional fields (alert_type, entity_id, custom payload) shown side by side.
• Centralized, declarative alerting that lives next to the workflow it protects.
• Zero custom code: no Python, no bash, no SDK to maintain.

Who it's for

• Platform and SRE teams routing pipeline failures into existing on-call rotations.
• Data engineers who want ETL, ELT, and reverse ETL failures to wake the right human.
• DevOps teams consolidating CI, infra, and orchestration alerts in one incident tool.

Why orchestrate this with Kestra

Zenduty integrations are great at managing incidents, but they do not know when your pipelines run, why they fail, or how to attach the right runtime context. Kestra fills that gap. The errors block runs only on failure, has access to every Pebble expression ({{ flow.id }}, {{ execution.id }}, {{ taskrun.id }}), and can be reused across hundreds of flows through subflows or pluginDefaults. You get event triggered alerts, automatic retries before paging, full execution lineage in the UI, and a single declarative YAML file that doubles as documentation for your on-call playbook.

Prerequisites

• A Zenduty account with an API integration created on a service.
• The integration key copied from the Zenduty integration settings.

Secrets

• ZENDUTY_INTEGRATION_KEY: the integration key from your Zenduty API integration URL.

Quick start

1. In Zenduty, create a new service or open an existing one and add an Events API integration.
2. Copy the integration key from the generated webhook URL.
3. Store it in Kestra as the secret ZENDUTY_INTEGRATION_KEY.
4. Copy this flow into your namespace and execute it. The fail task will exit with status 1.
5. Check Zenduty: an incident should appear within seconds, with the configured message, summary, and link.

How to extend

• Replace the fail task with your real workload (Python, SQL, dbt, Airbyte, Terraform, anything).
• Promote alert_type to critical for production and keep info for staging by templating it from a label.
• Inject runtime context into the payload: {{ flow.id }}, {{ execution.id }}, and a deep link to the execution in the Kestra UI.
• Move the errors block into a reusable subflow and call it from every production flow via io.kestra.plugin.core.flow.Subflow.
• Combine with retries on the failing task so Zenduty only fires after exhausting automatic recovery.

Links

• Zenduty plugin docs
• Zenduty Events API