Error handling in n8n: Retry, Continue on Error and Error Workflow explained

A n8n workflow that fails silently is a client email never sent, a document never ingested into your RAG index, or an audit trail with a gap nobody notices before the review. n8n ships three error-handling mechanisms that are often conflated: per-node automatic retry, the "Continue on Error" setting, and a dedicated error workflow. Combined correctly, they turn a fragile automation into a system that absorbs network blips, API rate limits, and malformed documents — and tells you when it actually matters.

Three mechanisms, three different jobs

It's tempting to handle everything with one checkbox. In practice, each mechanism solves a distinct problem:

• Retry On Fail — for transient errors: an API that's briefly down, a network timeout, a rate limit. The node retries on its own; the workflow continues as if nothing happened.
• On Error: Continue — for non-blocking errors: one malformed record out of a thousand, a row to skip without aborting the whole batch.
• Error Trigger + Error Workflow — for terminal errors: when everything else has failed, someone needs to know, with enough context to act fast.

All three combine on the same workflow: retry as the first line of defense, Continue on Error so a batch job doesn't stall on one bad item, and an Error Workflow as the final safety net.

Retry On Fail: the easy win, with one important caveat

In each node's Settings (the gear icon at the top of the node panel), enable Retry On Fail. Two fields follow:

• Max Tries — number of attempts, 2 to 3 to start.
• Wait Between Tries — delay in milliseconds between attempts. For a rate-limited API, 1000ms is a sensible floor; for embedding or generation model calls, push it to 3000–5000ms.

This is the single most cost-effective setting in this whole guide on an HTTP Request node or any AI model call: the vast majority of production failures are passing 429s or 503s, not real bugs. Retrying three times with a short delay silently resolves the overwhelming majority of cases.

The caveat to know: never enable Retry On Fail on a node with a non-repeatable side effect — sending an email, posting to Slack, inserting a row without a uniqueness constraint. A timeout that happens after the action actually succeeded server-side (but before the response reaches n8n) will trigger a retry — and a second action. On these nodes, let the failure surface as-is, or add a unique key at the database layer before you even consider retrying.

Continue on Error: process a batch without one item blocking it

Every node's Settings tab also exposes an On Error field with three values:

• Stop Workflow (default) — the execution halts immediately and the error propagates.
• Continue — the workflow proceeds on the node's normal output, with an error field mixed into the data.
• Continue Using Error Output — the node gains a second output, dedicated to failures, separate from the success output.

In practice, default to the third option whenever you're processing more than one item — a loop over emails, Supabase rows, or documents to ingest. It lets you wire two distinct paths: successes continue normally, failures go to a node that logs them or sets them aside for manual review — without ever halting the whole batch over a single bad item.

That's exactly the pattern used in a document-ingestion pipeline for a RAG assistant: out of a hundred PDFs to vectorize, if the twentieth is corrupted or unreadable, you want the other ninety-nine to ingest anyway, with the failed one landing in a list to review — not the whole batch grinding to a halt.

Error Trigger and Error Workflow: the global safety net

Retry and Continue on Error handle failures case by case, node by node. What's missing is a last line of defense: what happens when a workflow truly fails, despite all of it?

That's the job of the Error Trigger (errorTrigger), a special trigger node you place in a separate workflow dedicated to error handling. That error workflow is then attached to one or more business workflows via workflow Settings → Error Workflow (the ⋯ menu in the top-right of the editor), where you pick which workflow should fire on failure.

When a business workflow fails without any of its nodes having absorbed the error via Continue on Error, n8n automatically triggers the Error Trigger of the associated workflow, with an object like:

{
  "execution": {
    "id": "1847",
    "url": "https://your-instance.app/workflow/abc123/executions/1847",
    "error": {
      "message": "ETIMEDOUT: connect ETIMEDOUT",
      "stack": "..."
    }
  },
  "workflow": {
    "id": "abc123",
    "name": "Inbound email triage"
  }
}

From there, a minimal error workflow looks like: Error Trigger → a formatting node → Slack or Telegram. The message is worth crafting carefully, because it's the one you'll read at 10pm on a Friday:

🔴 Failed: {{ $json.workflow.name }}
Error: {{ $json.execution.error.message }}
View execution: {{ $json.execution.url }}

A single error workflow can be shared across all your business workflows — usually cleaner than duplicating an Error Trigger inside each one. Give n8n alerts their own Slack channel rather than mixing them into a general channel: noise kills attention far faster than silence does.

Log errors, don't just display them

A Slack alert scrolls out of view within a few days. For any workflow subject to traceability requirements — which covers most automations touching personal data or sensitive business processes — also insert every failure into a dedicated Supabase table, alongside or instead of the alert: workflow_name, execution_id, error_message, occurred_at. It's the same logic as the audit trail described in our GDPR audit trail with n8n and Supabase guide: an auditor or client asking "did you have any incidents on this process in March?" deserves an answer from one SQL query, not a search through Slack history.

Also worth knowing: the Save Data On Error setting, in the workflow's Settings (defaults to Save), keeps the input data of the failed execution available from the executions view. Without it, you know an error happened, but not on what data — a detail that changes everything when you sit down to debug.

Mistakes that cost an evening

• Continue on Error slapped on everything by reflex: the workflow never stops, but failures pile up invisibly — until a client asks why half their records were never processed.
• Retry on a node with a side effect: duplicate messages, emails, or database rows that are hard to spot after the fact.
• A single Error Trigger placed inside the business workflow itself instead of a separate one: it won't fire if the failure happens before that node is even reachable, notably on a trigger-level outage.
• No alert configured at all: the workflow fails, nobody knows, until a client notices before you do.
• Save Data On Error turned off to save storage: right when you need that data, it's gone.

Build this reliability without starting from scratch

Each of the four workflows in the AI Inbox Pack (€79) already ships with retry tuned for its AI and IMAP calls, and error alerts wired to Slack or Telegram. The Compliance & Audit Pack (€149) goes further with systematic logging — errors included — into an append-only Supabase table, exactly the pattern described above, ready to use. And if you want all three workflow families with this reliability baked in from the start, the Complete FlowKit Bundle (€269) bundles all of them.

An n8n workflow isn't done the day it works in testing — it's done the day you can trust its silence, knowing that if it ever failed, you'd hear about it before your client did.