Pipedream error handling → n8n Error Trigger and retries

In n8n, the Error Trigger node replaces the Pipedream error emails and $error workflows you relied on. Pipedream emailed you about unhandled errors by default and could auto-retry steps on the Advanced plan (errors, settings). n8n sends nothing until you set up an error workflow, so do this before you switch traffic, or failures will go unnoticed.

Mapping

Pipedream	n8n
Error email on unhandled errors (max one per error, per workflow, per 24 h)	Error workflow: Error Trigger → Send Email / Slack node
Global error workflow from the Workspace $error events source	One error workflow selected in many workflows' settings
Auto-retry (Advanced plan: up to 8 retries over 10 hours)	Retry On Fail per node (tries and wait time)
$.flow.rerun in a catch block	Retry On Fail, or a Wait node and a loop
try/catch that continues the workflow	Node setting On Error: Continue, or Continue (using error output)
throw new Error()	Stop and Error node, or throw in a Code node
Event inspector history	Executions tab (keep failed executions on in Workflow Settings)

Step 1. Build one error workflow

1. Create a workflow that starts with an Error Trigger node.
2. Add a Slack, Send Email or HTTP Request node that sends the details. The trigger provides execution.id, execution.url, execution.error, execution.lastNodeExecuted and workflow.name. execution.id and execution.url exist only if the execution was saved, and when the trigger node itself fails the payload has a trigger object instead of execution.
3. Save it. It doesn't need to be published, and you can't test it by running other workflows manually (Error Trigger docs).

A message template:

{{ $json.workflow.name }} failed at {{ $json.execution.lastNodeExecuted }}
{{ $json.execution.error.message }}
{{ $json.execution.url }}

Step 2. Attach it to every migrated workflow

Open each workflow → Workflow Settings → Error workflow → select the one you built. One error workflow can serve all of them.

Step 3. Set retries where Pipedream retried

Pipedream's auto-retry was a workflow setting that retried the failed step and continued from there. In n8n you set Retry On Fail on the nodes that call flaky APIs (node settings), usually HTTP Request and app nodes. Don't retry nodes with side effects that aren't idempotent (charging a card, sending an email) unless the API supports idempotency keys.

Step 4. Decide what continues on error

The node setting On Error has three options: Stop Workflow (default), Continue, and Continue (using error output). The last one gives the node a second output for failed items, which is the visual version of a try/catch around one call.

Executions and retention

Failed executions are your new event inspector. On self-hosted n8n, executions are pruned by default after 336 hours (14 days) or past 10,000 executions (execution data). On n8n Cloud, retention depends on the plan.

Next steps

• Full process: migrate Pipedream to n8n
• Branching around failures: control flow to n8n
• Find workflows that use $.flow.rerun: free report

Not affiliated with Pipedream or n8n.