Out of the box, one failed node halts the whole n8n execution, and unless someone is watching the executions list, it fails silently. For automation you actually depend on, that is not enough. n8n gives you three complementary tools — error workflows, continue-on-fail, and node retries — and a robust workflow uses all three deliberately.
A dedicated error workflow
The most important pattern is the Error Trigger. Build one workflow that starts with an Error Trigger node, and set it as the error workflow for your others. When any of them fails, n8n runs it and passes the full error context — which workflow, which node, the error message. That error workflow is where you notify a channel, log the failure, or open a ticket. This turns silent execution failures into an alert that reaches a human.
per node -> Retry On Fail (transient blips) -> handle in-place
per node -> Continue On Fail (tolerable failures) -> branch + handle
workflow -> Error Trigger workflow (anything else) -> alert + logContinue on fail for tolerable errors
Sometimes a single item failing should not kill the batch — one bad record out of a thousand should be logged and skipped, not fatal. Enable Continue On Fail on that node, and it passes the error along the output instead of throwing. Branch on the result to route failed items to a review queue while the good ones proceed. Use this deliberately, though: silently continuing past errors that actually matter just hides real problems.
Node-level retries
For transient failures — a timeout, a brief 5xx, a rate limit — enable Retry On Fail on the node with a sensible attempt count and wait. This handles the flaky-network reality that plagues any integration, resolving most transient issues before they ever reach your error workflow. Reserve the error workflow for failures that survive the retries.
Whichever mechanism catches a failure, it must end somewhere actionable — a Slack alert, an email, a row in a review table. n8n's executions list records failures, but nobody watches it proactively. An error caught and then dropped into a log no one reads is the same as an error not handled at all.
Layer n8n error handling from the inside out: node retries absorb transient blips, continue-on-fail keeps a batch alive past tolerable per-item failures, and a global Error Trigger workflow catches everything else and alerts a human. Configure all three intentionally and your automations fail loudly and recoverably instead of silently stopping.
Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.