n8n in Production: When the No-Code Magic Stops Working

Introduction

n8n is exceptional at the beginning. Visual editor, hundreds of integrations, fast iteration. Then your team adds 200 workflows over 18 months and operational pain catches up.

These are the five inflection points where teams graduate from n8n to Temporal, Camunda, or custom — and the migration strategies that work without rewriting from scratch. We'll cover what each limit looks like in practice, when to graduate vs. when to optimize, and the hybrid pattern most production setups land on.

If you're running n8n in production and starting to feel the pain, this post will help you decide what to do about it.

1. Long-running workflow durability

n8n executions are stateful within a run, but durability across process restarts is limited. When you need workflows that genuinely survive infrastructure events (multi-day approvals, weeks-long onboarding flows, scheduled multi-step processes), n8n starts losing executions in ways that are hard to debug.

What it looks like in practice

Symptoms we see:

• Workflows that should have triggered didn't.
• Workflows that started don't finish.
• Re-running a workflow produces different results than the original.
• Investigation reveals the workflow started, encountered a restart, and didn't recover correctly.

The Temporal alternative

Temporal's durable execution model is purpose-built for this. Workflows can sleep for weeks; the runtime replays state across restarts. Activities are idempotent by design. Multi-day approval workflows work correctly without manual intervention.

When to graduate: when you have workflows that must reach completion eventually (money movement, fulfillment, provisioning), n8n's durability model is the wrong tool.

2. Idempotency requirements

Re-running an n8n workflow is straightforward. Re-running it idempotently — guaranteed to produce the same result without duplicate side effects — is much harder.

For financial workflows, billing, or anything money-touching, idempotency isn't optional. A retry that creates a duplicate invoice or charges a customer twice is a serious incident.

What good idempotency looks like

Each side-effect action carries an idempotency key. Retries with the same key are guaranteed not to duplicate the side effect. State is recoverable across retries.

n8n has workarounds (you can build idempotency manually in each workflow) but the framework doesn't make it easy. Teams either get it wrong, or spend significant time building idempotency primitives that Temporal and Camunda provide out of the box.

3. Complex retry semantics

n8n has retry, but it's blunt. Production-grade workflows need fine control: exponential backoff with custom policies per tool, circuit breakers when downstream is unavailable, dead-letter queues for permanent failures, separate retry strategies for different error types.

Building these on top of n8n is possible. At some point, you're writing more code in n8n to work around its retry model than you would in a workflow engine designed for production retry semantics.

Symptom: retry workarounds proliferate

When your n8n workflows have dedicated "retry handler" nodes, custom backoff logic in JavaScript expressions, and dead-letter queues built in Postgres — you've outgrown n8n for those specific workflows.

4. Throughput at scale

n8n scales horizontally, but the cost curve gets steep. We typically see teams hit a wall around 100k+ executions per day where the infrastructure cost and operational complexity of running n8n at scale starts to compete with purpose-built engines.

Symptoms

You're running multiple n8n workers. Queue depth alerting becomes a regular thing. Performance tuning sessions consume engineering time. The infrastructure bill is significant.

Alternatives at scale

Temporal scales to millions of workflows. Custom workers running on dedicated infrastructure can be orders of magnitude more efficient for high-volume workflows. The trade-off is engineering complexity.

5. Cross-workflow debugging

When something breaks in production with 200 workflows running, n8n's execution history view is fine for individual investigations. It doesn't scale to "across these 200 workflows, find me all the executions that touched this customer's data in the last week."

Temporal's replay-based debugging shows you exactly what happened at each step of a failed workflow — which becomes invaluable when you're investigating issues across hundreds of executions.

The pain point

You discover a production issue that potentially affected multiple customers. You need to find every workflow execution that touched their data. In n8n, this involves manual queries against the database. In Temporal, this is built-in tooling.

When you should stay with n8n

Not every limit means you should graduate. Stay with n8n when:

• The pain points above don't apply to your specific workflows.
• Your team doesn't have capacity to operate a more complex tool.
• Non-engineers contribute to workflow maintenance — n8n's visual editor is irreplaceable for this.
• Your workflows are inherently simple integrations that n8n handles well.
• The cost of migration exceeds the operational pain.

Don't graduate just because you're hitting some friction. Graduate when specific workflows are causing repeated production issues that the framework can't solve.

Migration strategy: don't throw it all out

The most common mistake we see: teams hit a few n8n pain points and decide to migrate everything to Temporal. This is almost always wrong.

The right migration strategy:

• Identify the specific workflows causing pain. Usually 5-15 critical workflows out of 200. The rest are fine in n8n.
• Migrate those workflows to Temporal (or alternative). Engineering investment per workflow: 1-3 weeks depending on complexity.
• Keep the rest in n8n. Business automation, lightweight integrations, approval workflows — n8n still excels at these.
• Run both side by side. n8n for business automation; Temporal for business-critical orchestration.
• Don't consolidate on one tool. The right answer is usually multiple tools, each used where it fits.

Hybrid n8n + Temporal architecture

A production setup we ship frequently:

architecture
Business automation (n8n):
  Sales lead routing
  Marketing campaign workflows
  CRM enrichment
  Notification routing
  Document approval workflows
  ... 200+ light workflows

Business-critical orchestration (Temporal):
  Subscription billing flows
  Order fulfillment
  Customer onboarding (multi-day)
  Account provisioning
  Fraud-flagged transaction handling
  ... 10-30 high-value workflows

Shared infrastructure:
  Same database
  Same monitoring (Datadog)
  Same alerting (PagerDuty)
  Same SSO and auth

The two engines share underlying infrastructure but handle different workload types. Total ops complexity is higher than one engine, but lower than forcing one engine to handle both workload types.

Conclusion

n8n is a great tool that handles a specific kind of workflow well. When you hit its limits, the answer is rarely to migrate everything — it's to identify the specific workflows that need a different tool and migrate those.

Most production stacks at scale run multiple workflow engines. n8n for business automation, Temporal for business-critical orchestration, Airflow for data pipelines. Each tool used where it fits.

If you're hitting n8n production limits and trying to figure out what to do, we help clients prioritize migration candidates and architect the hybrid pattern. Usually 80% of workflows stay in n8n; 20% migrate to engines purpose-built for the specific pain point.