New to Kestra?
Use blueprints to kickstart your first workflows.
Send an alert to Sentry when any flow fails in the company namespace
Automatically raise a Sentry issue whenever any Kestra workflow in the company namespace fails or warns, with severity and a direct link to the failed execution.
Categories
id: failure-alert-sentry
namespace: system
tasks:
- id: send_alert
type: io.kestra.plugin.sentry.SentryExecution
executionId: "{{ trigger.executionId }}"
transaction: /execution/id/{{ trigger.executionId }}
dsn: "{{ secret('SENTRY_DSN') }}"
level: ERROR
triggers:
- id: failed_prod_workflows
type: io.kestra.plugin.core.trigger.Flow
conditions:
- type: io.kestra.plugin.core.condition.ExecutionStatus
in:
- FAILED
- WARNING
- type: io.kestra.plugin.core.condition.ExecutionNamespace
namespace: company
prefix: true
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
- A
io.kestra.plugin.core.trigger.Flowtrigger listens for executions across other flows. - Two trigger conditions filter the noise:
io.kestra.plugin.core.condition.ExecutionStatusfires only onFAILEDorWARNINGoutcomes, andio.kestra.plugin.core.condition.ExecutionNamespacematches any namespace starting with thecompanyprefix. - When both conditions match, the
send_alerttask of typeio.kestra.plugin.sentry.SentryExecutionposts an event to Sentry using your projectdsn, tags it withlevel: ERROR, and setstransactionto/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
transactionvalue that links each Sentry event to the exact Kestra execution. - Centralized incident visibility next to your existing application errors.
- Configurable severity through the
levelproperty (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, condition blocks 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
- Store your Sentry DSN as the
SENTRY_DSNsecret. - Adjust the
ExecutionNamespaceprefix to match the namespace you want to monitor. - Add this flow to your instance and let it run on the trigger.
- Fail a test flow in the monitored namespace and confirm the issue appears in Sentry.
How to extend
- Tune
levelper namespace or environment to separate critical failures from warnings. - Add more conditions 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
Share this Blueprint
Create a Blueprint
Go to the developer platformMore Core Blueprints
More System Blueprints
