Send an alert to Sentry when a flow fails

Turn Kestra workflow failures into actionable Sentry incidents. This blueprint wires Sentry error tracking directly into your orchestration layer, so every failed flow surfaces in your Sentry dashboard with the namespace, flow ID, execution ID, and a direct link back to the run. Instead of polling logs or waiting for someone to notice a broken pipeline, your on-call team gets a Sentry event the instant something breaks, with the context needed to triage it fast.

How it works

1. The flow runs its normal work. Here a single io.kestra.plugin.core.execution.Fail task stands in for whatever real task you want to guard, forcing the execution into a failed state for demonstration.
2. When any task fails, Kestra routes execution to the errors block.
3. The alert_on_failure task of type io.kestra.plugin.sentry.SentryAlert fires, authenticating with your dsn and sending a JSON payload to Sentry.
4. The payload is templated with runtime values like {{ execution.id }}, {{ flow.namespace }}, {{ flow.id }}, and {{ execution.startDate }}, plus a clickable link straight to the failed execution in the Kestra UI.

What you get

• Automatic Sentry events on flow failure, no manual instrumentation in your task code.
• Failure context (namespace, flow, execution ID, link) attached to every alert via the extra payload field.
• Centralized incident tracking: pipeline errors land in the same Sentry project as your application errors.
• A reusable error-handling pattern you can drop into any flow.

Who it's for

• Data and platform engineers who already use Sentry for application monitoring and want pipeline failures there too.
• On-call and SRE teams that need fast, contextual notifications when orchestrated jobs break.
• Teams standardizing observability across services and data workflows.

Why orchestrate this with Kestra

Sentry is built to capture errors from running applications, but it has no scheduler and no concept of a pipeline failing. Kestra fills that gap. The errors block is event driven: it reacts the moment a task fails, no cron polling required. You define the alerting once in declarative YAML and attach it to any flow, you can layer retries on upstream tasks so Sentry only fires on genuine failures, and execution metadata flows in automatically for lineage and traceability. The result is a single, versioned definition of both your work and how failures get reported.

Prerequisites

• A Kestra instance with the Sentry plugin available.
• A Sentry account and project to receive events.

Secrets

• SENTRY_DSN: your Sentry project DSN, found under project settings in the "Client Keys (DSN)" section. See the Sentry DSN docs.

Quick start

1. Add a SENTRY_DSN secret to your Kestra instance.
2. Copy this blueprint into a flow and set the namespace.
3. Run it once: the fail task triggers the error path and a test event appears in Sentry.
4. Confirm the event shows the execution link and context, then adapt the flow to your real tasks.

How to extend

• Replace the fail task with your actual pipeline tasks; the errors block guards all of them.
• Customize the payload JSON to set level, transaction, server_name, or add fields to extra.
• Set an event_id (a UUID) in the payload to group related failures, or omit it to let Kestra generate one.
• Add complementary alerts (Slack, email, PagerDuty) in the same errors block for multi-channel notifications.

Links

• Sentry plugin documentation
• Sentry Event Payloads reference