The idea is:
When a workflow fails, the built‐in Error Trigger should include all of the original trigger’s input parameters. For example, if the workflow was started by a Webhook Trigger, the Error Trigger should receive and expose every HTTP header, query parameter, body payload, etc., that the Webhook originally received. Likewise, for any other trigger type (e.g. Cron, Schedule, Email, WebSocket, etc.), the Error Trigger should surface the exact parameters or payload that launched the workflow.
My use case:
- Webhook‐driven workflows: I need to capture the entire incoming HTTP request when errors occur, so I can replay, debug, or enrich error notifications with full context.
- Scheduled or time‐triggered workflows: When a scheduled job fails, I want to know the exact execution timestamp, timezone, and any custom options I set on the trigger.
- Event or integration triggers (e.g. IMAP-Email, WebSocket, AWS SNS): On failure, I need the raw event message or metadata that was consumed, to assist in troubleshooting and rerunning workflows without guesswork.
I think it would be beneficial to add this because:
- Improved observability & debugging: Including the original trigger data in error events makes it trivial to see “what went in” without searching logs or reconstructing inputs.
- Faster recovery & retries: With full input context available, you can automatically rerun or simulate failed executions in a single step.
- Better notifications: Error emails, Slack alerts, or PagerDuty incidents can include rich trigger context (payload, headers, query params), reducing back-and-forth when investigating issues.
- Consistency across triggers: Standardizing on “always forward trigger inputs to the Error Trigger” simplifies user expectations and documentation.
Any resources to support this?
- n8n Webhook Trigger documentation
- Existing GitHub discussion on enhancing Error Trigger payloads: GitHub · Where software is built (if applicable)
- Similar behavior in Zapier: when a Zap fails, the task history shows full input data for each action.
Are you willing to work on this?
Yes – I can help prototype the change, write up tests, and contribute code or documentation updates once the design is agreed upon.
```