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

Get a Sentry issue raised the moment a Kestra workflow fails so on-call engineers triage incidents in the same place they already track application errors. This monitoring flow watches every execution in the company namespace and forwards failures and warnings to Sentry, turning silent pipeline breakages into actionable, deduplicated alerts with severity, transaction context, and a direct link back to the failed run.

How it works

1. A io.kestra.plugin.core.trigger.Flow trigger listens for executions across other flows.
2. A single dependsOn entry filters the noise: states: [FAILED, WARNING] fires only on those outcomes, and its when expression ({{ trigger.namespace startsWith 'company' }}) matches any namespace starting with the company prefix.
3. When both the states and the when expression match, the send_alert task of type io.kestra.plugin.sentry.SentryExecution posts an event to Sentry using your project dsn, tags it with level: ERROR, and sets transaction to /execution/id/{{ trigger.executionId }} so the issue points straight at the offending execution.

What you get

• Automatic Sentry issues for every failed or warning execution, no manual reporting.
• A transaction value that links each Sentry event to the exact Kestra execution.
• Centralized incident visibility next to your existing application errors.
• Configurable severity through the level property (DEBUG, INFO, WARNING, ERROR, FATAL).

Who it's for

• Platform and data engineers running production pipelines who need fast failure signals.
• On-call and SRE teams that already standardize on Sentry for incident management.
• Teams consolidating workflow observability into one alerting tool.

Why orchestrate this with Kestra

Sentry captures errors but does not know when your scheduled pipelines break. Kestra closes that gap: the event-driven Flow trigger reacts to other executions in real time rather than polling, the dependsOn states and when expression keep alerts scoped and relevant, and the entire monitoring policy lives in declarative, version-controlled YAML. Built-in retries, execution lineage, and the {{ trigger.executionId }} context give every alert traceability that a standalone error tracker cannot produce on its own.

Prerequisites

• A Sentry project with an active DSN.
• Kestra with the Sentry plugin available.

Secrets

• SENTRY_DSN: the Client Key (DSN) from your Sentry project settings under "Client Keys (DSN)".

Quick start

1. Store your Sentry DSN as the SENTRY_DSN secret.
2. Adjust the namespace prefix in the trigger's when expression to match the namespace you want to monitor.
3. Add this flow to your instance and let it run on the trigger.
4. Fail a test flow in the monitored namespace and confirm the issue appears in Sentry.

How to extend

• Tune level per namespace or environment to separate critical failures from warnings.
• Extend the when expression to scope alerts to specific flows, labels, or tags.
• Chain a Slack or email notification alongside the Sentry event for redundant alerting.
• Enrich the Sentry payload with custom context about the failing execution.

Links

• Sentry plugin documentation
• Where to find your DSN
• Sentry event payloads