Pass Custom Metadata to Error Workflows

Feature Requests
1

The idea is:

When configuring an Error Workflow, provide an optional section for defining custom fields that will be passed to the Error Workflow execution.

The configuration experience could be similar to the Set (Edit Fields) node, allowing users to define custom metadata such as:

  • Workflow owner name

  • Workflow owner email

  • Team name

  • Environment (Production, Staging, Development)

  • Project identifier

  • Any other custom fields

These values would then be available in the Error Workflow payload alongside the existing error information.

My use case:

I use centralized Error Workflows to handle failures across multiple workflows.

When a workflow fails, I often need additional context to determine who should be notified or which team owns the workflow.

Being able to pass metadata such as owner email, owner name, team, or environment directly from the workflow configuration would make centralized error handling much easier and more maintainable.

I think it would be beneficial to add this because:

  • It would simplify centralized error management.

  • It would enable more informative Slack, email, or incident notifications.

  • It would reduce duplication and hardcoded logic.

  • It would improve support for teams managing many workflows.

  • It would make Error Workflows more flexible and reusable.

For example, a single Error Workflow could automatically know who owns the failed workflow and who should receive notifications, without requiring additional lookups.

Any resources to support this?

No specific resources. This request is based on practical experience building centralized monitoring and alerting workflows in n8n.

Are you willing to work on this?

I would be happy to discuss the implementation and provide feedback on the UX and expected behavior.

2

This would be really useful - right now the only workaround is to set static data at the workflow level ($getWorkflowStaticData('global')) and read it inside the error workflow, but that requires manual setup per workflow. A built-in metadata section in the error workflow config would make this much cleaner, especially for teams managing multiple client environments.

3

This is a genuinely useful feature request, and for teams running multiple client environments it is the difference between an error workflow that is actionable and one that just says “something broke somewhere.” The static-data workaround above works, so here is how to make it less painful until a built-in lands.

Set the metadata once per workflow in a Set node at the very start (owner, team, environment, client name) and write it into the workflow’s static data, then your error workflow reads it via $getWorkflowStaticData(‘global’). To avoid configuring it by hand on every workflow, keep a single sub-workflow that returns the metadata for a given workflow ID from one central table (a Data Table or an external sheet), and have each workflow call it at start. New workflow, one row in the table, no per-workflow editing.

The reason this matters beyond convenience: an error workflow that does not know which client or environment it fired for makes you go digging at exactly the moment you want to move fast, and across many client workflows that lookup time is where a quick fix turns into a slow one. Centralizing the metadata is worth it once you are past a handful of workflows. How many environments are you routing errors for right now?

2 Likes