I run our entire content pipeline on self-hosted n8n: ten workflows, around 209 nodes, on one small box, turning trend signals into scripts, voiceovers, rendered videos, and scheduled posts every day. The visual canvas is genuinely good, and for the first hour it feels like automation is a solved problem — you drag in a trigger, wire up some nodes, and the happy path just works.
Then it runs a few thousand times, and you discover the thing no-code tools quietly don't tell you: production automation is a distributed-systems problem, whether or not you called it that. The moment a workflow makes network calls, writes to a database, or posts to an external service, you inherit the same hard questions a hand-written backend would — and a visual builder makes the happy path free while handing the rest straight back to you.
Here are the four that bit us, and how you actually deal with them. None of this is a knock on n8n specifically; it's honest about giving you the primitives. It just doesn't solve these for you.
1. Retries aren't free — you need idempotency
Every serious automation tool has a "retry on failure" toggle, and n8n's is one setting per node. It feels like a safety net. It's a trap if you don't think about it.
The problem is at-least-once delivery. If a node posts to a social scheduler, then the next node fails and the run retries from a checkpoint — or you re-trigger the workflow to recover — the post fires twice. The retry doesn't know the side effect already happened. Anything non-idempotent (publishing, sending, charging, inserting a row) will happily run again.
The fix is the same one you'd use in any backend: make the side-effecting step idempotent, or guard it with state. We put a status column in front of the non-idempotent steps, so a step is a no-op if it already ran:
// n8n Code node, before a publish step
const row = $input.item.json;
if (row.status === 'published') {
// already sent — don't double-post on a retry/retrigger
return [];
}
// ... do the publish, then flip status = 'published' in the next node
It's a boring pattern, but the visual canvas won't suggest it, because from the canvas's point of view a retry is just "run the node again."
2. Partial failure needs an explicit path you have to build
The happy path is a straight line you can see. The failure path is invisible until you draw it — and by default, a step that throws just stops that one execution, silently, wherever it happened to be.
Two rules keep this sane for us. First, a dedicated error workflow: n8n lets you point every workflow at one error handler, so we run a small four-node "heartbeat" that catches any failure anywhere in the pipeline and pings our team chat with which workflow died and why. Nothing fails in the dark.
Second, and this is a policy more than a feature: no silent fallbacks. When a step can fail, we let it fail loudly — it throws and propagates, it does not quietly return a cheaper or emptier result that looks like success. A silent fallback is how you end up shipping an empty render or a half-built post and finding out from a viewer. If a call fails, the run turns red and the heartbeat tells us. Loud failure is a feature.
3. Concurrency and ordering are yours to enforce
This is the one that surprised me most, because it's not about any single node — it's about two workflows sharing a resource.
Part of our pipeline drives headless Chrome to render frames. On a small box, two of those running at once will fight over memory and fall over. n8n has no idea these two workflows contend for the same physical resource; it'll happily fire both when their triggers line up.
So we reach outside n8n for the coordination: the render steps take a Postgres advisory lock before touching Chrome, and release it after, so only one render runs at a time and the rest queue behind it. The lesson generalizes — any shared external resource (a rate-limited API, a single-writer file, a GPU) needs a lock or a queue the workflow engine doesn't know about and won't create for you. If ordering matters, you own it.
4. Data-shape drift fails silently
The last one is the quietest. n8n's Postgres node returns JSONB columns as real JS arrays and objects, which is lovely — until a SELECT omits one of those columns. Then a downstream Code node doesn't see an empty array; it sees undefined. And a guard like if (row.scenes.length === 0) doesn't return "empty" — it throws, or worse, a row.scenes?.length check passes as "fine" and you process a record that's actually missing its data.
We got bitten when a fetch query didn't include every JSONB field a later validator read. The fix is unglamorous: select every field your validators touch, and assert the shape at the boundary with an If node before you trust the data, exactly like you'd validate an API response you didn't control. Treat the previous node's output as untrusted input, because across a few thousand runs, eventually it is.
The honest takeaway
None of this makes n8n a bad tool — the opposite. It's why we picked it over a fully-hosted no-code option: it gives you real Code nodes, error workflows, and the escape hatches to solve all four of these properly. That's also exactly why it's the wrong tool for someone who wants automation to "just work" on day one without thinking about idempotency or locks — the same power that lets you fix these problems is the power that makes you responsible for them.
If you want the fuller picture of where that trade-off lands — the learning curve, the self-hosting ops burden, the per-execution billing that made it worth it for us at volume — I wrote it all up in my hands-on n8n review after running it in production. But the short version is the lesson above: no-code buys you the happy path for free, and production is where you pay for the rest.
