Three ways a clever workflow lets you down

By now you can switch a workflow from Manual to Schedule so it runs by itself at 8:00 every morning, and you can split, merge and batch the data going through it. The workflows look clever. Here is what clever looks like on a bad week.

n8n has a ready answer for each one. An error workflow covers the first, retry covers the third, and the Wait node covers the second. They are not alternatives you pick between. They are three layers of insurance that a production workflow should carry at the same time: tell you it broke, let a single point rescue itself, and avoid hammering the other side to begin with.

Three names that look alike and work at completely different levels

Lay the three cards on the table before you touch anything, because beginners mix them up constantly. Retry means this one node tries again by itself. An error workflow means the whole workflow has already given up. Five failed retries → the workflow dies → only then is the error workflow called.

The order they fire in matters, and it is worth having the picture in your head before you build anything.

flowchart TD
  A["A node fails mid-run"] --> B{"Is Retry On Fail turned on
for this node?"}
  B -->|"no"| D
  B -->|"yes"| C{"Are there tries left?
Max Tries counts the first run"}
  C -->|"yes"| C1["Pause for Wait Between Tries,
then call the node again"]
  C1 --> C
  C -->|"tries used up"| D["The workflow dies"]
  D --> E{"Does this workflow have an
Error Workflow set, and is
that handler Active?"}
  E -->|"no"| F["Nobody is told.
You find out on Monday"]
  E -->|"yes"| G["The Error Trigger fires
inside Error Handler"]
  G --> H["A message names the workflow,
the node and the error"]

One error workflow for the whole company

An error workflow is a separate, standalone workflow. Not a setting — a whole workflow, sitting in your Workflows list like any other. The one thing that makes it special is that its first node has to be an Error Trigger.

It works in three moves. Build the error workflow first, with an Error Trigger at the front and Slack, email, Discord or a database behind it — that answers “who gets told when something breaks, and where does it get logged?” Point every other workflow at it in their own Settings. Then, when one of them fails, n8n triggers the error workflow automatically and hands it the failure data.

sequenceDiagram
  participant S as Schedule Trigger
  participant W as Daily report workflow
  participant N as n8n
  participant E as Error Handler
  participant K as Slack
  S->>W: the 8 am run starts on its own
  W->>W: the HTTP Request node fails
  W->>W: retries, and fails again
  W-->>N: no tries left, the workflow dies
  N->>E: call the workflow named in Error Workflow
  E->>E: Error Trigger receives the failure data
  E->>K: post to the alerts channel
  K-->>N: you know within seconds, not on Monday

The Error Trigger node puts the error information into $json. These are the five fields you will use most:

Building the Error Handler

The goal: a workflow that posts a message to the Slack #alerts channel whenever something fails. Set it up once, and every workflow you write afterwards uses it.

1. Step 1

   Create a new workflow and name it Error Handler

   Go to Workflows in the left sidebar → + Add workflow. With the canvas still blank, press Ctrl+S to save and type the name Error Handler. Pick something recognizable — you will be looking for it in a dropdown later, and a workflow called “My workflow 7” is no help there.

2. Step 2

   Add the Error Trigger node

   Press Tab on an empty part of the canvas, or use the + in the top left, to open the nodes panel → search for Error Trigger → pick it. It lands on the canvas as this workflow's starting point. The Error Trigger has no parameters to set. Dropping it in is all you do.

3. Step 3

   Add a Slack node behind it

   Drag a connection out of the Error Trigger's right side and let go to open the nodes panel → search for Slack → pick the Send a message action. If you have not set up a Slack credential yet, create one now — an OAuth authorization for your Slack workspace.

4. Step 4

   Set the Channel

   The Channel field lets you pick an existing channel By Name, or you can type #alerts straight in. Create that channel in Slack first and invite the n8n bot into it, from the Slack channel → Integrations → Add App menu. A message sent to a channel the bot is not in fails, and that failure has nothing above it to catch it.

5. Step 5

   Write the message with expressions

   Switch the Text field to Expression mode — the fx button at the top right of the field — and paste in a body built from the fields above. The source guide's version opens with a warning-sign line, then these five, one per line:

   Workflow: {{ $json.workflow.name }}

   Failed at node: {{ $json.execution.lastNodeExecuted }}

   Error message: {{ $json.execution.error.message }}

   Time: {{ $json.execution.startedAt }}

   Open it here: {{ $json.execution.url }}

   The preview underneath the field shows a sample filled with dummy data. If that reads like a message you would want at three in the morning, you are done with this step.

6. Step 6

   Save, then flip Active

   Press Ctrl+S, then turn the Active toggle in the top right green. An error workflow that is not Active never fires. This is the number-one gotcha in the whole chapter.

7. Step 7

   Leave it alone

   Once the Error Handler is set up there is nothing to tend day to day. It is called and runs once, only when another workflow fails, and takes no resources at all the rest of the time.

Pointing every workflow at it

The Error Handler existing does nothing on its own. You still have to go into each production workflow and point it at the handler, one at a time. It is not applied automatically.

1. Step 1

   Open the workflow you want watched

   Click into it from the Workflows list and the canvas opens.

2. Step 2

   Three-dot menu, top right → Settings

   Or press Ctrl+,. The Workflow Settings panel opens, with options such as Timezone, Save Failed Executions and Error Workflow. Your build may lay this panel out differently — go by the field names rather than their position.

3. Step 3

   Pick Error Handler in the Error Workflow dropdown

   The dropdown lists every workflow on your instance that contains an Error Trigger node — and only those. Find Error Handler and click it.

4. Step 4

   Save Settings

   Save sits at the bottom right of the panel. From now on this workflow triggers Error Handler automatically when it fails.

5. Step 5

   Repeat for every production workflow

   Make a list and work through it in one sitting. Then set it on new workflows as you create them, while you are already in the Settings panel choosing a timezone.

Letting one node rescue itself

Retry on fail is an automatic retry set on a single node. When that node fails, n8n waits a moment and calls it again, waits and calls again, and only declares failure once the tries run out. It suits transient errors: an API returning 503 for a while, a network wobble, the other system restarting.

To set it, open the panel of the node you want to retry — HTTP Request, Slack, Google Sheets, any node can have it. The top of the node panel has two tabs, Parameters and Settings. Click Settings, then turn Retry On Fail on. Two fields appear.

flowchart TD
  A["A node keeps failing.
Should it retry?"] --> B{"Would running this node twice
send, create or charge twice?"}
  B -->|"yes"| B1["Leave Retry On Fail off.
Put a check-first node in front,
or let it fail and be told"]
  B -->|"no"| C{"Is the error transient?"}
  C -->|"503, 429, network timeout"| C1["Retry On Fail on.
Max Tries 3 to 5"]
  C -->|"401, 404, a wrong expression"| C2["Retry will not help.
Fix the cause instead"]
  C1 --> D["For 429, push Wait Between Tries
to 5000 ms or more"]

There is a companion setting worth knowing about while you are in the same tab. Alongside Retry On Fail, a node's Settings has an On Error option — older versions called it Continue On Fail, so recognize the shape rather than the word. It answers a different question: when this node fails for good, does the whole workflow die? Three choices:

• Stop Workflow — the default. The workflow dies, and the error workflow gets called.
• Continue — the node fails but emits empty data, and the run carries on.
• Continue (using error output) — the node grows an extra error branch, and the failed data goes down it.

Continue suits the case where one node failing is acceptable and you want to keep going: batch-processing 100 customers, 3 of them fail, and the other 97 still have to be finished. It combines with retry — three retries, still failing, then Continue moves on to the next batch.

Pausing on purpose

The Wait node does one very simple thing: it stops the workflow here and only moves on when the time is up. You use it to slow things down, to line up with a clock, or to wait for an outside system to answer. These are the three modes you will use most:

The most common pattern by far is Wait paired with Split In Batches to stay under a rate limit. Say you have to call an outside API for 500 records. Firing all 500 at once gets you rate-limited.

flowchart LR
  A["500 records arrive"] --> B["Split In Batches
batch size 10"]
  B --> C["HTTP Request
10 calls go out"]
  C --> D["Wait
After Time Interval, 1 second"]
  D --> B
  B --> E["All batches done"]

That comes out at roughly 10 requests a second, which usually sits inside what the other side allows.

Reading the record after the alert

The error was caught and the alert went out. Next you open the Executions page and find out which node failed and why. This is where most of your debugging happens. There are two ways in: Executions in the main sidebar shows the records for every workflow on the instance, while the Executions tab at the top of an open workflow shows only that one.

Each record carries a colored status, and the colors are the fastest thing on the page to read.

Click into any red execution and you get a canvas-style view of that run. The failed node is highlighted with a red border, and clicking it shows the input, the output and the error message from that specific run. This is the fastest way to find a bug in n8n.

stateDiagram-v2
  state "Error Handler runs" as Handler
  [*] --> Running: an automatic trigger fires
  Running --> Waiting: the run reaches a Wait node
  Waiting --> Running: the time is up, or the callback arrives
  Running --> Success: every node ran through
  Running --> Error: a node failed for good
  Error --> Handler: n8n calls the bound error workflow
  Success --> [*]
  Handler --> [*]

Pin data, so testing does not burn your quota

Rerunning a workflow after every small change keeps hitting the real APIs — Gmail, Slack, Sheets. That is slow, and it eats quota you may be paying for. Pin data lets you pin one successful output of a node. On later reruns the workflow takes the pinned data at that node instead of calling the API for real.

Get one successful run, click that node's output, and press the pin icon above it. The output is now fixed. When you want to see what a downstream change did, rerun the workflow and the pinned node hands back the pinned data. Unpin it once you are done building, before you go live — a pinned node in a production workflow is a node that has quietly stopped talking to the outside world.

The failure you meet, and the fix that goes with it

Here are the errors that come up most often, matched to what to reach for, so that next time a message appears you can look the fix up rather than work it out.

The other category is “I set it up and nothing happened.” Work through these and you can usually rescue it yourself.

Where to go from here