A workflow that runs cleanly in the n8n editor during testing tells you very little about how it will behave in production. Real failures come from upstream APIs going down, rate limits triggering mid-run, malformed data from a source that changed its schema without notice, and network timeouts on the tenth item of a hundred-item batch. None of that shows up until the workflow has been running unattended for a while.
The Default Behavior Is Not Enough
Out of the box, a node that fails stops the workflow. For a workflow that runs once, triggered manually, that’s fine. For anything scheduled or webhook-triggered and running without supervision, a single bad API response killing the entire run — and silently not running again until someone notices — is the most common way “working” automations quietly stop working.
Retries Belong on Anything That Calls an External Service
Any node that makes an HTTP call, hits a third-party API, or depends on network reliability should have retry logic with backoff rather than a single attempt. n8n supports configurable retries at the node level — the setting is easy to skip when a workflow is first built and expensive to have skipped once it’s been running unattended for a month.
Error Workflows, Not Just Error Notifications
n8n lets you attach a dedicated error workflow to catch failures from a main workflow — logging what failed, why, and with what input data, rather than just firing a generic “something broke” alert. That distinction matters when you’re debugging at 2 a.m.: a Slack message that says “workflow failed” is far less useful than one that includes the failing node, the input it received, and the error returned.
Idempotency Prevents the Second-Order Problem
When a workflow retries after a partial failure, it needs to not duplicate the work that already succeeded — sending the same email twice, creating a duplicate record, publishing the same post again. Building workflows so that re-running them from a failure point is safe (checking for existing records before creating new ones, using idempotency keys on external calls) is what separates automation you can trust from automation you have to babysit.
What Reliable Actually Looks Like
A production-grade n8n workflow has retries on external calls, a real error-handling workflow that captures context, alerting that tells you what broke rather than just that something did, and idempotent steps so a retry doesn’t create a second-order mess. This is the part of automation work that doesn’t show up in a demo but is most of what determines whether a workflow survives contact with production — it’s a core part of how CodeixLab scopes automation projects.