When to reach for n8n (and when to write a worker instead)

Summary: Use n8n for inspectable, moderate-volume integrations; move to custom workers when you need idempotency, tests, and strong observability—or combine both in a hybrid pattern.

n8n is great for the messy middle: glueing CRMs, email, spreadsheets and APIs together, with a visual record of what runs when. But it is a poor fit for high-volume pipelines, anything with strict latency, or workflows that need real testing.

Choosing between n8n and custom code

Use n8n when

• The non-engineer who owns the process needs to inspect runs
• Volume is under a few thousand events per day
• Most steps are HTTP calls or simple transforms

Write a worker when

• You need retries, idempotency keys and good observability
• The logic is more than ~20 nodes — it stops being readable
• The data is sensitive enough that "click around in a UI" is the wrong governance model

The hybrid pattern that works

Often the answer is not either/or: use n8n for orchestration and visibility, but hand off heavy or sensitive steps to a small worker (queue consumer, Edge function, or cron) that implements idempotency, structured logging, and unit tests. n8n becomes the control plane; code becomes the data plane.

Observability and change management

Export workflows to JSON, store them in git, and treat changes like any other PR. For on-call, you need alerts when a workflow fails or silently stops — not an email buried in someone's inbox. Name workflows and nodes so the next person can understand the intent without opening twenty branches.

Quick checklist

Before committing to n8n for a new integration: Is volume predictable and under a few thousand events per day? Can the business owner read the execution log? If the answer to both is yes, n8n is a strong default. If either is no, prototype in n8n, then plan which pieces graduate to code.