Send workflow errors to Sentry

Help me Build my Workflow
1

I would like to automatically open an issue in the Sentry monitoring system when a workflow fails (self-hosted n8n, self-hosted sentry).

The “dealing with errors” documentation only talks about mail, slack and telegram - and the Sentry Node actions don’t allow creating issues / sending errors.

Sentry itself is able to send internal errors to sentry since PR 4394, but not workflow errors.

What could I do?

1 Like
2

Welcome @cweiske!

You can skip the Sentry node entirely and use the Error Trigger + HTTP Request node to POST directly to Sentry’s Envelope API (the same endpoint the SDK uses). Set up a separate error-handling workflow with the Error Trigger as the start node, then add an HTTP Request node pointing to https://sentry.example.com/api/<project_id>/envelope/ with your DSN key in the X-Sentry-Auth header.

The body needs to follow Sentry’s envelope format - at minimum a header line and an event payload in JSON, separated by newlines. You can build this in a Code node before the HTTP Request:

const header = JSON.stringify({event_id: $execution.id.replace(/-/g,''), sent_at: new Date().toISOString(), dsn: 'YOUR_DSN'});
const eventMeta = JSON.stringify({type:'event'});
const event = JSON.stringify({level:'error', message: $json.execution.error.message, logger: $json.workflowData.name});
return [{json: {body: [header, eventMeta, event].join('\n')}}];

Set the HTTP Request body to raw/text and pass {{ $json.body }}. This gives you full control over what data lands in Sentry without needing the Sentry node at all.

1 Like
3

One small guard before wiring this to Sentry: send an event and let Sentry group it, instead of trying to create an issue directly. Set a stable fingerprint so retries from the same broken workflow/node collapse into one issue.

For the Error Trigger payload, build the fingerprint from the workflow id/name, the failed node name, and the error message/class. Add execution id as a tag, not part of the fingerprint. Then fail the same workflow twice; the good result is one Sentry issue with two events, not two issues.

4

This does exactly what you two described — Error Trigger → build a Sentry envelope → POST to your /envelope/ endpoint (skipping the Sentry node, like @nguyenthieutoan said), with the stable fingerprint @oimrqs_ops called out.

The fingerprint is [workflow name, failed node, error class + message], so repeated failures of the same workflow collapse into ONE Sentry issue; the execution id rides along as a tag, not in the fingerprint. Send the same workflow’s failure twice and you get one issue with two events.

Two edits before it runs: the URL (your-sentry-host/api/PROJECT_ID/envelope/) and the sentry_key in the X-Sentry-Auth header (your DSN public key). Then set this workflow as the Error Workflow on the ones you care about (Settings → Error Workflow) and it catches them all.

1 Like