When an Automation Needs to Become Industrial

The Zapier vs Make vs n8n debate fills the forums, but it asks the wrong question. Our thesis: the move from lightweight automation to industrial-grade orchestration is decided on five measurable criteria — event volume, business criticality, observability, cost per execution, and error recovery. Not on a tool preference, not on a team habit.

This thesis is refutable, by design: all four platforms studied — Zapier, Make, n8n, Trigger.dev — scale up. The industrialization threshold is therefore not a boundary between tools: it is the point where the patterns change — queues, log exports, chunking, configured and tested retries.

At Ownward, this grid is part of how we build: measure first, choose second. The figures below — all verified on August 12, 2026 — ground that measurement.

None of the four platforms bills the same thing. Each vendor bills what its engine measures — that is architectural information, not a commercial footnote.

Take a 10-step workflow triggered 10,000 times a month: roughly 100,000 tasks on Zapier, roughly 100,000 operations on Make, exactly 10,000 executions on n8n, a compute-second volume driven by actual processing time on Trigger.dev, plus $0.25 in invocations. Four very different invoices for the same need.

The pattern: beyond a few thousand monthly events on multi-step flows, recompute the same flow in all four units before making any call — the real cost is never visible on the entry price.

Rising volume does not break these platforms: it triggers documented regulation mechanisms. Their shape, not their existence, should drive capacity planning.

The cross-platform pattern: beyond about a hundred simultaneous events, immediate execution becomes a queue with controlled replay. The right question is no longer "will the tool hold?" but "is the drain time compatible with the business?": 1,000 events drained at one execution per second means 15 minutes of latency on the last one — fine for a contact sync, not for a payment confirmation.

A practical tip: at the same vendor, the pricing page and the limits page may show different concurrency figures (observed on August 12, 2026). Size against the limits documentation, validate with a load test.

A workflow that runs is not a workflow that is observed. Execution log retention is the criterion most often discovered too late — during the incident.

The pattern: beyond the number of audit days your business requires, exporting logs to storage you control becomes the required level — whatever the vendor. On self-hosted n8n, the defaults are readable from the configuration:

EXECUTIONS_DATA_PRUNE=true          # rolling pruning enabled by default
EXECUTIONS_DATA_MAX_AGE=336         # 14 days of execution data
EXECUTIONS_DATA_PRUNE_MAX_COUNT=10000
EXECUTIONS_TIMEOUT=-1               # no timeout by default
EXECUTIONS_MODE=queue               # queue mode for scale-out

What doing nothing costs — A flow running 5,000 executions a month with 2% silent failures loses 100 events per month. Detected after a quarter, the incident covers roughly 300 events, and most of their traces have expired — the four platforms' standard retention, 1 to 69 days depending on the plan, does not cover a quarter. What remains is manual reconciliation, record by record, in the source systems.

All four platforms offer error recovery. None fully enables it for you: durability is an explicit engineering choice, not an emergent property of the tool.

• Zapier: autoreplay of errored runs on Professional, Team and Enterprise, configurable at account level or per Zap ("Always replay" / "Never replay"); autoreplay targets runs in "errored" status, "safely halted" runs are handled by manual replay from the history, and the public documentation stays qualitative about retry timing.
• Make: a Retry error handler that keeps the error message and mappings and replays supported temporary errors (connection, rate limit) — documented example: 3 attempts every 15 minutes; incomplete execution storage is off by default and enabled scenario by scenario.
• n8n: "Retry on Fail" set node by node (Max Tries, Wait Between Tries in milliseconds), complemented by dedicated error workflows.
• Trigger.dev: declarative, code-first retries with exponential backoff, disabled by default in the DEV environment at initialization:

retry: {
  maxAttempts: 10,
  factor: 1.8,
  minTimeoutInMs: 500,
  maxTimeoutInMs: 30_000,
  randomize: true,
}

The pattern: everywhere, recovery is designed, configured and tested. If a flow touches revenue, the failure test — cut the target API, watch the replay — belongs in acceptance testing. It is the criterion that most sharply separates convenience automation from industrial-grade orchestration.

This grid condenses the five criteria into concrete decisions: thresholds, never a brand — the situation, not the logo, triggers the level change.

If two or more rows apply to the same flow, you are already in industrial territory. This is the kind of audit we run in our method: one day is usually enough to screen a portfolio of flows against these seven rows.

This grid assumes measurable volume and criticality. It does not apply to prototypes, POCs or one-off migrations: there, lightweight tooling without configured recovery is the right call, and industrializing it would be over-engineering. It also ignores two very real factors: team skills — a TypeScript team does not approach a visual tool the way an ops team does — and the ecosystem already in place (licenses, connectors, support habits). Finally, the figures quoted are public prices and quotas as of August 12, 2026: they move, sometimes differently from one page to another at the same vendor. The grid holds; the exact thresholds deserve a fresh check at every decision.