Set up alerts for failed workflow executions using Sentry

Catch failed workflow executions in Sentry without bolting alerting onto every flow you run. This system flow listens for any execution that ends in FAILED or WARNING across your Kestra instance and pushes a structured event to Sentry, so on-call engineers see pipeline failures in the same issue tracker they already use for application errors. Centralized failure alerting means one place to maintain, one DSN to rotate, and consistent severity across every namespace.

How it works

• A io.kestra.plugin.core.trigger.Flow trigger watches the whole instance for completed executions.
• An io.kestra.plugin.core.condition.ExecutionStatus condition filters those events down to executions whose status is FAILED or WARNING.
• When the condition matches, the send_alert task (io.kestra.plugin.sentry.SentryExecution) sends the event to Sentry, tagging it with the failing executionId, a transaction deep link back to the execution (/execution/id/{{ trigger.executionId }}), and a level of ERROR.
• The Sentry connection is authenticated with a dsn pulled from {{ secret('SENTRY_DSN') }}, so no credential is ever hardcoded.

What you get

• Instant Sentry issues for every failed or warning execution, instance wide.
• A clickable link straight back to the failing execution in the Kestra UI.
• One flow to maintain instead of alerting logic copied into hundreds of pipelines.
• Severity you control through the level property.

Who it's for

• Platform and data engineering teams running many flows who want a single alerting choke point.
• On-call and SRE engineers who already triage in Sentry and want pipeline failures there too.
• Teams standardizing observability across namespaces.

Why orchestrate this with Kestra

Sentry has no view into your orchestration layer on its own, it only knows about events you send it. Kestra closes that gap: the event-driven Flow trigger reacts to execution outcomes the instant they happen, the declarative YAML keeps the alerting policy in version control, and the ExecutionStatus condition lets you scope exactly which outcomes page someone. You get retries, full execution lineage, and a single source of truth for failure handling that no standalone scheduler or per-script try/except can match.

Prerequisites

• A running Kestra instance with the Sentry plugin available.
• A Sentry project with a DSN.

Secrets

• SENTRY_DSN: the Sentry Data Source Name (DSN) used to authenticate and route events to your Sentry project. Find it under Sentry project settings, "Client Keys (DSN)".

Quick start

1. Copy your Sentry DSN from your project's "Client Keys (DSN)" settings.
2. Store it in Kestra as a secret named SENTRY_DSN.
3. Add this flow to your instance.
4. Trigger any flow that fails or warns and confirm the issue appears in Sentry.

How to extend

• Restrict alerting to specific namespaces by adding an ExecutionNamespaceCondition to the trigger.
• Adjust level (DEBUG, INFO, WARNING, ERROR, FATAL) to match your severity policy.
• Customize the Sentry event payload to add tags, fingerprints, or contextual metadata.
• Chain additional notification tasks (Slack, email, PagerDuty) after send_alert for multi-channel paging.

Links

• Sentry plugin documentation
• Secrets in Kestra
• Monitoring and alerting guide