How I keep n8n workflows reliable when third-party APIs fail

Most n8n workflows I review fail in the same unglamorous way. The happy path works in a test run. Then a payment API times out, a CRM returns a 429, or a webhook is delivered twice, and the workflow either stops mid-way or writes the same record twice. The business only notices when a customer is billed twice, or when a lead never arrives. I have spent 16 years in IT, the last five in Dubai, building and reviewing automation for small teams. Reliability is a design choice, not a setting you flip on later. Below is the pattern I use when a workflow has to talk to third-party APIs and still be safe to rerun. The three failure modes that actually matter It helps to stop thinking in “success versus error” and start thinking in three buckets. Transient failures are timeouts, 502/503 responses, and rate limits. A retry, after a pause, often works. If you retry immediately and without a limit, you can make the rate limit worse. Permanent failures are 401s, 404s, schema changes, and validation errors. Retrying these is a waste of time and can lock an account or fill an error log. These should go to a human, with the payload preserved. Partial completion is the dangerous one. The CRM contact was created, then the invoice call failed. Or the invoice was created, then the confirmation email failed. A naive retry of the whole workflow creates a duplicate. This is how “simple” automations quietly damage operations. If a workflow can create, charge, email, or update a record, it needs an answer for all three. Design the workflow as steps with a recorded outcome I no longer build long linear chains that assume every node succeeds. Each meaningful step should: Check whether it has already been done. Do the work, or skip it if the record already exists. Store the external ID or a status flag. Only then move on. A Google Sheet, a row in Postgres, or a record in your CRM can be the source of truth. The workflow is not the source of truth; the data it writes is. When n8n restarts, or a webhook is replayed, the workflow should read that state and continue from the unfinished step, not from the beginning. A practical layout looks like this: Inbound: webhook or schedule, with a unique key (form ID, order ID, email plus date, or a UUID you generate once and persist). Load or create the job record: one row per business event, with fields such as status, crm_id, invoice_id, and last_error. Branch on status: “new”, “crm_done”, “invoice_done”, “notified”, “failed_permanent”. Do only the next unfinished step. Write the result back before calling the next API. This is more work than a demo workflow, and it is the difference between a tool you trust and a tool you babysit. Retries need a budget, not hope n8n can continue on fail, and it can retry. Those features are useful only with rules. For transient errors I use a short retry budget: a few attempts, a delay between them, and a clear stop. I log the HTTP status and a truncated body. I do not retry forever, or on every status code. For permanent errors I skip retries and write the payload to a dead-letter place: a dedicated sheet tab, a table, or a Telegram message that includes the job ID. “Continue on fail” without that record is how work disappears. I also keep retries close to the failing node. Wrapping an entire 20-node workflow in one blanket retry is how you get duplicate side effects. Make every create operation idempotent If the API supports an idempotency key, use it. Many payment and billing APIs do. Send the same key on a retry and the provider should return the original result instead of a second charge. If the API does not support that, build your own check: Search for an existing contact by email before creating one. Store the external ID on your job record the moment you get it. On retry, if crm_id is already present, skip the create node. For emails, store a notified_at timestamp and refuse to send twice. The unique key must come from the business event, not from the time n8n happened to run. Webhooks are often delivered more than once, and a queue retry will run the same job again. That is normal. The workflow has to be safe under those conditions. Alert on unresolved work, not on every handled retry A noisy Telegram or Slack channel trains people to ignore it. I alert when: A job sits in a failed state after the retry budget is used up. A job is older than a threshold and still not in a terminal status. An authentication error appears (these usually mean a token expired, and every job will fail until someone fixes it). I do not alert on the first timeout that later succeeds. I do keep a daily digest of jobs that needed a retry, because a rising count is an early warning that a vendor is degrading. What to test before the workflow goes live Before I trust a workflow with real customers, I run a short set of ugly tests: Replay the same webhook twice, immediately. Kill the workflow after the first successful create, then run it again. Force a 429 or a timeout on one node and confirm the job resumes without a duplicate. Revoke a token and confirm the alert is clear. If those four tests pass, the workflow is usually safe enough for a small team. If they have never been tried, I assume it will fail in production. I also prefer fewer well-owned workflows over a large pile of quick zaps. Reliability work does not scale linearly with the number of automations. The same ideas sit behind the n8n work I publish at https://alecasgari.com/services/n8n-automation. If you are comparing tools rather than designing a specific workflow, I also wrote a practical comparison at https://alecasgari.com/blog/n8n-vs-make-vs-zapier. Reliability will not make a messy process elegant. It will stop a useful process from creating duplicate invoices and missing leads. That is the bar I set before an automation runs unattended. I am Alec Asgari. If you want a second pair of eyes on a workflow that already fails in one of these ways, write to hello@alecasgari.com.