Simple error-handling setup every n8n workflow should have

Tips & Tricks
1

A lot of the “my workflow silently stopped working” questions here come down to missing error handling. Here’s a simple setup that covers most cases:

  1. Create one shared error workflow. Start it with an Error Trigger node, then send yourself a message (Slack, email or Telegram) with the workflow name, the failed node and the error message.
  2. Attach it to your important workflows. In each workflow’s settings, select it as the Error Workflow. One alert workflow covers everything.
  3. Turn on Retry On Fail for flaky nodes. HTTP requests to external APIs often fail once and then work. Two or three retries with a short wait avoid most false alarms.
  4. Choose On Error behaviour on purpose. For nodes where one failed item shouldn’t stop the whole run, set the node to continue and route the error output to a separate branch you can log or review.
  5. Log what matters. Before the final step, store key fields (record ID, timestamp, status) somewhere you can search later. Debugging gets much faster.

What else do you add to your workflows to make them reliable? Always looking to improve this list.

2

One extra check I’d add is deliberately testing failure paths before deployment. A shared Error Trigger and retries are useful, but they won’t catch every silent failure.

For critical workflows, I’d test a failed API call, a partial batch failure, and a retry of a non-idempotent operation. I’d also verify that alerts actually arrive and use an external heartbeat to detect workflows that stop running entirely.

Those are exactly the kinds of reliability checks I’m exploring with FlowPrecheck. Curious which failure scenarios others test before deploying.