3 n8n mistakes I made

The second one fails silently.

If your n8n workflows keep breaking, you may be making the same mistakes I made.

One client workflow used to break almost every week. I kept fixing the failed node, running it again, and moving on. That worked until the next failure.

I eventually fixed the design instead of the latest error. I have not touched that workflow in four months.

None of the three problems came from the AI. They came from retry logic, missing alerts, and careless batching.

These mistakes are easy to make because the workflow looks correct on the canvas. The problems appear later, when an API slows down, an email provider accepts a message but returns a bad response, or a large data set reaches production.

Here is what broke, why it broke, and what I use now.

Mistake 1: I turned on Retry On Fail everywhere

Retry On Fail sounds like free reliability. If a node fails, n8n runs it again.

I enabled it on almost every node. Then I enabled it on a node that sent an email. The client received the same email three times.

The mistake was treating every action as safe to repeat.

A retry does not undo the first attempt. An email service can accept a message while the response back to n8n times out. From n8n's side, the attempt looks unsuccessful. The retry sends the message again.

The same risk applies to actions that charge a card, create an invoice, place an order, add a CRM record, or publish a post.

The fix: retry only when repetition is safe

I now separate nodes into two groups.

Read actions fetch data. These are usually safer to retry. Examples include reading a contact, checking an order, or requesting a document.

Write actions change something outside n8n. These need protection before they are retried. Examples include sending a message, collecting a payment, or creating a record.

For a normal API request, n8n lets you set Max Tries and Wait Between Tries inside the node settings. The wait matters because an immediate retry can hit the same temporary problem or rate limit. (n8n: Handling rate limits)

For a write action, I use this check:

1. Create a unique operation ID, such as the order ID plus the action name.
2. Check a database or data table for that ID.
3. Continue only if the action has not completed.
4. Send the request.
5. Record the result and the provider's reference ID.

If the external API supports an idempotency key, I send the operation ID with the request. The provider can then recognize a repeated request and avoid performing the action twice. This is safer than relying only on a local "sent" flag, because the connection can fail after the provider accepts the request but before n8n saves the result.

If the provider has no idempotency support, I avoid automatic retries on sensitive actions. I send an alert and review an uncertain result before trying again.

My rule now

Retry a read. Protect a write.

Before enabling Retry On Fail, ask: "What happens if the first attempt worked, but n8n never received the success response?"

If the answer involves a duplicate email, payment, order, or record, add a guard first.

Mistake 2: I had retries but no error workflow

This was worse because I did not find out first.

The node tried again. It failed again. The workflow stopped. No alert reached me. The client reported the problem.

To be precise, n8n had not deleted the failure. It was available in the execution history. The problem was that I had no system watching that history and telling me something needed attention.

A production workflow should never depend on someone remembering to check the Executions page.

The fix: one central error workflow

n8n supports a separate error workflow. It starts with an Error Trigger and runs when a linked automated workflow fails. You assign it inside the main workflow's settings. The same error workflow can monitor several workflows. (n8n: Error handling)

My basic error workflow follows this path:

Error Trigger → Format Error → Send Alert → Save Incident

The alert should contain enough information to act without opening five different screens:

• workflow name,
• failed node,
• error message,
• execution link,
• time of failure,
• customer or job reference, when available.

I send the alert to the channel the team already watches. That can be Slack, Microsoft Teams, email, or an incident system. I also save the incident so repeated failures can be counted and reviewed later.

How to set it up

1. Create a new workflow.
2. Add the Error Trigger as the first node.
3. Add an Edit Fields node to prepare a readable message.
4. Add the notification node your team uses.
5. Optionally save the incident in a database or n8n Data Table.
6. Open each production workflow.
7. Go to Workflow Settings.
8. Select the new workflow under Error Workflow.

n8n notes that the Error Trigger runs for automatic workflow failures, not ordinary manual test runs. Use a controlled automatic execution when testing the alert path. You can also use Stop And Error when you need a workflow to fail under a condition you choose. (n8n: Error Trigger)

There is another trap here. If you configure a node to continue after an error, the workflow may keep going instead of ending as a failed execution. That can be useful when the failure is expected, but you still need a branch that records or reports the problem. Do not confuse "continue" with "resolved."

My rule now

Every production workflow needs an owner and an alarm.

If nobody receives the failure, the workflow is not monitored. It is only running.

Mistake 3: I used a batch size of one

The third mistake cost money.

I used Loop Over Items, previously called Split in Batches, and set the batch size to one. A thousand records became a thousand separate passes through the loop. In my workflow, that also meant a thousand API calls. I hit the service's rate limit before lunch.

A batch size of one is not always wrong. It is useful when each record truly needs a separate request or when an API allows only a very slow request rate. The mistake was choosing it without checking what the destination API could accept.

n8n already processes input items automatically for most nodes. You often do not need to build a manual loop. Loop Over Items is useful when you need controlled batches, a delay, or a repeated process with a clear stopping condition. (n8n: Looping)

The fix: design around the API limit

Before adding a loop, I check four things:

1. Can the destination accept several records in one request?
2. How many requests are allowed per second or minute?
3. Does the API provide a bulk endpoint?
4. What should happen when one record inside a batch fails?

If the API accepts bulk payloads, I group records into the largest safe batch and send the group in one request. If it requires one request per record, I control the pace with a batch interval or a Wait node.

The HTTP Request node has built-in batching controls. Items per Batch controls how many input items n8n processes in a batch. Batch Interval adds a pause between batches. n8n describes this as the built-in alternative to a Loop Over Items plus Wait pattern. (n8n: HTTP Request batching)

Do not assume that raising Items per Batch automatically creates a bulk API payload. The destination endpoint must support bulk input, and the request body must be shaped the way that API expects. Batching can control execution speed, but the API contract decides whether several records can share one request.

A simple sizing example

Suppose an API allows 100 records in one bulk request and 10 requests each minute.

For 1,000 records:

• batch size 1 can require 1,000 requests,
• batch size 100 can require 10 requests.

That is a large difference in cost, time, and rate-limit risk.

The correct batch size is not always the largest number. Large batches can use more memory and make partial failures harder to recover. Start below the provider's limit, measure the result, and increase carefully.

My rule now

Count the requests before running the records.

I calculate the expected number of API calls using a small sample before sending the full data set. If 20 test records create 20 requests, I know what will happen when the input reaches 10,000.

The production checklist I use now

Before I publish an n8n workflow, I check the following:

Retries

• Is the failure temporary and worth retrying?
• Is the action safe to repeat?
• Does the API support an idempotency key?
• Are Max Tries and Wait Between Tries reasonable?
• What happens if the action succeeded but the response was lost?

Errors

• Is an error workflow assigned?
• Does the alert reach a channel someone watches?
• Does the message include the workflow, node, error, and execution link?
• Are failures saved for later review?
• Has the error path been tested through an automatic execution?

Volume

• How many input records will the workflow receive?
• How many API calls will that create?
• Does the API support bulk requests?
• What are the rate and payload limits?
• Can one failed record be retried without repeating the whole batch?

Ownership

• Who receives the alert?
• Who decides whether to retry?
• How quickly must the workflow recover?
• What is the business impact if it stays broken?

Reliability is part of the workflow

I used to think a workflow was finished when the happy path worked.

Now I consider it finished when it handles duplicate attempts, reports failures, and survives the real volume it was built for.

The AI node is often the part people worry about. In my case, the expensive failures happened around it. A retry repeated an external action. A missing error workflow hid a failure. A batch size multiplied the number of requests.

This is not theory. It is just what broke on me.

Check your error workflow first. Then check every node that sends, creates, charges, or publishes something. Finally, count the API calls your largest real input will create.

Those three checks take less time than explaining a duplicate email to a client.

If you want my n8n guard template, comment GUARD on the original post or contact me through ahmedsalama.co.

Recommended visuals

Hero image

Use a real n8n canvas screenshot with three problem nodes marked in red: Send Email, Error Handling, and Loop Over Items. Blur client names, credentials, URLs, email addresses, and execution data.

Suggested overlay: "3 n8n mistakes I made"

Suggested alt text: "n8n workflow showing retry, error handling, and batching problems."

Visual after mistake 1

Create a simple before-and-after graphic.

Before: Send Email → Retry → Duplicate Email

After: Check Operation ID → Send Once → Save Result

Visual after mistake 2

Use a screenshot of the error workflow:

Error Trigger → Edit Fields → Slack or Email → Incident Log

This is the most useful screenshot in the post because readers can rebuild it.

Visual after mistake 3

Create a small comparison card:

1,000 records × batch size 1 = up to 1,000 requests

1,000 records ÷ 100 per bulk request = 10 requests

Add a note: "Only when the API supports bulk requests."

Social sharing image

Use a 1200 × 630 image with this text:

3 n8n mistakes I made

The second one fails silently.

Keep the n8n canvas visible in the background and use one strong orange accent.

Sources

• n8n documentation: Error handling
• n8n documentation: Error Trigger
• n8n documentation: Looping
• n8n documentation: Handling rate limits
• n8n documentation: HTTP Request node