n8n Error Handling and Retries: AI Workflows That Don't Break

n8n Error Handling and Retries: AI Workflows That Don't Break

To handle errors and retries in n8n, turn on retry only for nodes that are safe to repeat (such as the LLM call), with a cap on attempts and a wait between them. Then route final failures to an error workflow that alerts a person and gives the customer a fallback reply. The core idea is to separate generating the reply from sending the reply: only the first step can be repeated without risking a duplicate message.

Key takeaways

• LLM API failure is routine, not an exception. Rate limits, slowness and temporary outages happen, and the workflow has to plan for them.
• Retry without a cap and without criteria causes two problems: duplicate messages to the customer and runaway spend.
• Repeat only steps that can be redone without side effects. Sending to the customer needs a control key that blocks a second send.
• Every final failure needs two destinations: an alert to the team and an exit for the customer (a fallback reply or a handoff to a human).
• Test failures on purpose before going live, because the error path is almost never exercised by accident.

Why do LLM failures cause duplicates or silence?

An AI workflow in n8n usually follows a simple sequence: a message arrives (through a webhook, for example), the workflow builds the context, calls the model, validates the answer and sends it to the customer. Every step depends on an external service, and any of them can fail.

Silence happens when the LLM node errors out and the workflow simply stops. With default settings, n8n halts the execution and the customer gets no reply. Nobody on the team sees it, because the failure only shows up in the executions list, which nobody keeps open all day.

Duplicates have two common sources. The first is applying retry to a node that already had a side effect, for example repeating a whole block that includes the message send. The second is the sender resending the webhook because your workflow took too long to acknowledge it, so n8n processes the same event twice. Payment providers document this repeated-delivery behavior in their webhook guides, and the logic applies to any event source: assume the same event can arrive more than once.

The design mistake behind both problems is the same: treating the workflow as a straight line that always ends well, instead of a process with states (received, generated, sent, failed).

Which errors deserve a retry and which do not?

Before turning on any retry, classify your errors. Repeating an error that is not temporary only delays the problem and burns calls.

• Rate limit exceeded: worth retrying, with a longer wait between attempts.
• Timeout or provider server error: worth retrying, a few times.
• Authentication or permission error (invalid key, expired key, no credit): do not retry. This is a configuration failure, and the alert should go straight to whoever administers the workflow.
• Malformed request (missing field, context too large for the model): do not repeat the same call. Fix the input or shrink the context. For more on that limit, see what a context window is in AI.
• Model output in the wrong format or rejected by validation: at most one new generation, and only if your validation step is reliable. After that, hand off to a person.
• Failure sending to the channel (WhatsApp, email): retry only if a control key guarantees the message did not go out on the previous attempt.

Exact error codes vary by provider. Check the documentation of the API you use and record the decision for each error class. That table becomes part of the workflow's handover material.

How do you configure capped retries in n8n?

In n8n, error settings live on each node, in the settings tab. Names can change between versions, so confirm in the official documentation for your version. In general you will find three relevant controls.

• Retry On Fail: turns on automatic repetition when the node fails. It exposes the maximum number of attempts and the wait time between them.
• On Error: defines what happens when the node finally fails. It can stop the workflow, continue and ignore the error, or continue using a separate error output.
• Timeout on HTTP calls: if you call the model through a request node, set a maximum time so a hung call does not hold the workflow indefinitely.

On the attempt limit, the practical rule is to keep the number low. A model call costs money and time, and the customer is waiting. Two or three attempts usually cover passing failures, and anything beyond that is a problem that needs a person.

The wait between attempts in the built-in retry is fixed. If your case needs a growing wait (common with rate limits), build a small loop: a counter, a wait node whose time increases on each pass, and a condition that exits the loop when the counter reaches the maximum. The counter is mandatory. A loop with no ceiling is the same class of problem described in AI agent infinite loops and step limits, with the added issue of spend on every pass.

The most important point is order: enable retry on the LLM node, never on a block that contains the send. If the model is called twice and only the second answer is sent, the customer notices nothing. If the send is called twice, they notice.

How do you avoid duplicate messages even with retry?

The tool for this is called idempotency: repeating the operation with the same key produces the same effect as running it once. Payment providers formalize this idea in their API documentation on idempotent requests. In n8n, you implement the equivalent with a control table.

The design works like this:

• Every incoming message carries a unique identifier (the channel's message ID). Use that value as the key.
• At the start of the workflow, look up the control table (it can be a spreadsheet, a database or n8n's own Data Table, depending on your version). If the key already exists with the state sent, end the run without doing anything.
• If the key does not exist, write it with the state processing and continue.
• After a successful send, update the state to sent.
• If the workflow fails midway, the processing state remains, and the error workflow knows that conversation needs attention.

One operational detail: respond to the incoming webhook quickly. If the sender waits for an acknowledgment while your workflow spends time calling the LLM, it may resend the event. Confirming receipt first and processing afterward lowers the chance of a resend, and the control key covers whatever is left.

If the channel is WhatsApp, remember it has its own rules on when you can send a message. An automatic resend outside the service window may require an approved template. The article on WhatsApp outbound messages, templates and opt-in covers that point, and the guide to integrating AI into your company's WhatsApp covers the overall architecture.

How do you build the error workflow and alerts?

n8n lets you designate an error workflow: a second workflow, started by the Error Trigger node, that fires when a main workflow fails in an automatic execution. You link it in the main workflow's settings, in the error workflow field. Two cautions: it does not fire on manual test runs, and you must link each important workflow to it, because the connection is not global.

The Error Trigger delivers data such as the workflow name, the node where it failed, the error message and the execution identifier. With that, the error workflow should do four things.

• Notify a person, in a channel they actually watch (an internal group, an on-call email). The alert should say which workflow failed, at which node, and include the execution link.
• Mark the conversation as pending in the control table, so no message is forgotten.
• Send the customer a short fallback reply when it makes sense, or trigger the handoff to human support.
• Prevent alert storms: if the model provider goes down, many executions fail together. Group the notices or limit their frequency, otherwise the team starts ignoring the channel.

For failures you want to handle inside the workflow itself, use the option to continue with an error output on the LLM node. That output leads to a branch that decides: try an alternative model, use the fallback reply, or forward to a person. The Stop And Error node is useful for forcing a deliberate failure when validation rejects the answer, so the error workflow is triggered with a clear message.

Do not treat the alert as the end of the work. Log each failure with date, node, error class and outcome. That history is what lets you see patterns, and general observability concepts (logs, metrics and traces) help you think about this without depending on a specific tool. To validate model output before sending, see guardrails for AI agents.

On privacy: the alert should not carry the text of the customer's conversation. Send identifiers and links to the execution, and keep the content accessible only to people with permission in n8n. This reduces exposure of personal data in internal chat channels, which matters for LGPD.

Illustrative scenario: a distributor and a rate limit

Illustrative scenario: an electrical supplies distributor receives quote requests on WhatsApp. The workflow reads the message, calls the model to extract items and quantities, checks stock and replies with a confirmation.

On a busy morning, the model provider starts returning rate limit errors. In the poor design, the LLM node sits inside a block together with the send, and retry is turned on for the whole block. The result: some customers receive the confirmation twice, others receive nothing, and the team finds out in the afternoon.

In the corrected design, the sequence changes. The message ID is written to the control table before anything else. Retry sits only on the LLM node, with a few attempts and a longer wait. If the limit persists, the error branch marks the conversation as pending, sends the customer a line such as "we received your request and an agent will confirm shortly", and alerts the internal group once. When the provider recovers, the team reprocesses the pending items from the table with no risk of duplicates, because the state of each one is recorded.

Step-by-step plan and how we apply the method

Use this sequence to review an existing workflow or build a new one.

• List the workflow's nodes and mark which ones have side effects (sending a message, writing to the CRM, creating an order).
• Split the workflow in two parts: generating the reply (repeatable) and delivering the reply (controlled by a key).
• Create the control table with the message key, the state and the date.
• Turn on retry only for nodes without side effects, with a low maximum number of attempts and a wait between them. Set a timeout on calls.
• Configure the LLM node's error output and write the fallback reply, reviewed by someone who knows your customer service.
• Create the error workflow with Error Trigger, an alert to a person, a pending marker and a limit on alert frequency.
• Link the error workflow to each main workflow.
• Test on purpose: invalid API key, forced timeout, off-format answer, webhook sent twice. Confirm that nothing duplicates and nothing goes silent.
• Define who receives the alert, at what hours, and what that person does first.

The method we use in these projects follows the same logic. Map: draw the current process and where it can fail. Limit: fix the attempts, time and actions the workflow is allowed. Pilot: run a real workflow with logs and an agreed success criterion, including provoked failures. Transfer: hand over documentation of known errors and what to do for each, so operations do not depend on whoever built it. This kind of ongoing follow-up is what Be Human covers in managed operation.

Frequently asked questions

How many retries should I configure in n8n for an LLM call? Few. Two or three usually cover passing failures, and more than that increases the customer's wait and the spend without improving the chance of success. If the failure persists, the right path is the error workflow, not more attempts.

Can n8n retry cause duplicate messages? It can, if it is turned on for a node that already produced an effect, such as the send to the customer, or if the same incoming event is processed twice. The defense is to keep retry on the generation step and use a control key, such as the message ID, to block a second send.

Does the n8n error workflow run on manual test executions? In general, no. It is triggered by automatic executions, such as those started by a webhook or a schedule, so you should test the error path by activating the workflow and causing a real failure. Confirm the behavior in the documentation for your n8n version.

What should the customer receive when the AI model is down? A short, honest reply saying the request was received and a person will continue the conversation, together with an actual handoff to a human. Avoid promising a deadline you do not control, and avoid repeating the message each time the customer writes again.

Sources

• Stripe: requisições idempotentes
• Stripe: entrega e verificação de webhooks
• OpenTelemetry: conceitos de observabilidade