Hi everyone!
I’m continuously learning n8n and trying to improve my workflow-building skills.
I want to understand how experienced automation developers handle errors in real-world workflows.
A few questions:
When an API request fails, how do you automatically retry it?
How do you use the Error Trigger node in production workflows?
How do you prevent duplicate data when a workflow runs again after failure?
What is your approach to logging errors and notifying clients?
I’d love to hear how you handle error management in your real-world n8n projects.
I’m here to learn from the community and improve my automation skills.
Thanks in advance!
Hey @abid_zia, while you wait for a response, here are some things that might help:
Suggested resources
Automatically matched to your question.
Docs:
Forum:
@Niffzy - you’ve helped with similar issues before, can you take a look?
Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.
Hi @abid_zia, I’d start with one shared error workflow and make each write safe to repeat.
-
Retries: Open the API node’s Settings → Retry On Fail, cap the attempts and set Wait Between Tries (ms). Use this for temporary failures on requests that are safe to repeat.
-
Error Trigger: Create and publish
Error Trigger → log → Slack/email, then select it under the main workflow’s Settings → Error workflow. Test with an automatic trigger and Stop And Error; manual editor runs don’t fire the error workflow. -
Duplicates: For database records, use the source event/order ID as a unique key and upsert instead of inserting again. For API writes, reuse the same provider-enforced idempotency key for each logical action across retries and reruns. A timeout can happen after the write succeeds, so uncertain outcomes need reconciliation if the API has no idempotency support.
-
Logging and clients: Record the workflow name, failed node, error message, timestamp and execution link when available. Alert internally after retries are exhausted; send the client a short impact/status message when their work is affected.
A safe email/CRM pattern is to keep a durable record keyed by the source event ID with states queued → sending → sent, plus unknown for a timeout after a possible remote write. On retry, replay only queued items; reconcile unknown against the provider/CRM or route it to a person. This avoids treating a red execution as proof that nothing happened. Test with a timeout after the provider accepts an email, then run recovery twice; neither recovery should create a second send.
One thing worth adding is to separate expected failures from unexpected ones. On the HTTP Request node, set On Error to “Continue (using error output)” and branch on status code once retries run out. A 404 or 422 is usually a data problem and can go to a “needs review” path. A 429 or 5xx can go to a delayed retry. That way the Error workflow only catches what you didn’t plan for.
Also throttle the alert side. During an outage, one bad API can fire hundreds of Slack pings. Log every failure to a table, but alert once per workflow per hour or send a digest.
Since the thread only has the truncated header, I can’t see what approaches were already suggested, so I’ll keep this general. For workflow failures, the useful baseline is an error workflow set in the workflow settings, which catches unhandled node errors and gives you the execution ID and failing node. From there, logging failures somewhere durable (a database or sheet) helps spot patterns rather than reacting to single alerts. On retries, be careful with nodes that aren’t idempotent, since a retry can create duplicates. What kind of failures are you hitting most, timeouts, auth, or data shape issues?
Turn on Retry On Fail in the settings of the HTTP node, with a wait between tries. Put an Error Trigger in its own workflow that sends you a Slack or email message with the workflow name and execution link. For duplicates, write with an upsert on a unique ID instead of a plain create, so a rerun just overwrites the same record.
Two things I lean on in client workflows that nobody has mentioned yet.
First, batch runs. When a workflow processes lots of items, one bad record shouldn’t kill the whole run. Set the node that hits the API to Continue using error output, branch right after it, and collect the bad ones into a separate failed-items list you log at the end. You end up fixing 3 records instead of re-running 500.
Second, when a run dies mid-way, don’t rebuild it. Turn on Save execution progress in the workflow settings, then open the failed execution and hit Retry. It resumes from the node that failed instead of starting over, which matters when the first 20 nodes took 10 minutes. One catch: if any earlier node has side effects like sending emails, a full retry will fire those again, so keep side-effect nodes guarded with a check on whether the work already happened.
And test the error branch on purpose. Feed the node a fake 500 and a malformed payload and watch what actually happens. Retry On Fail will happily retry a request that can never succeed.
Good advice above. One thing I’d add: check that the error handling itself works, and look for failures that never throw an error.
Two things that bit me on a production instance:
- An error workflow can be set in Settings and still be dead. I’ve found one pointing at itself, one pointing at a workflow that was never published, and one blocked by the target’s “This workflow can be called by” setting. n8n accepts all three. So run the test Anshul describes on every workflow, not only the first one.
- A schedule that stops firing produces no error, so no Error Trigger will tell you. The same goes for a failure caught by an error branch: the execution still ends as success. You can only catch these from the outside, by comparing when each schedule should have run with the executions that exist.
I built a small daily check for these cases and published it as a free template, in case it’s useful: Send daily workflow health digests with the n8n API and Gmail | n8n workflow template