Zapier vs Make vs n8n after a fortnight on each

Step six failed at 03:40 on a Tuesday. That is the moment that actually separates these three products, and it is nowhere in the comparison tables, which are all built around connector counts. Everybody has the connectors. Zapier's directory is enormous, Make's is close enough that the difference only shows up at the edges, and n8n covers the common services plus an HTTP node that will talk to anything with a REST endpoint. If your shortlist depends on whether a platform integrates with Slack, you do not have a shortlist problem.

We ran the same four workflows on all three, a fortnight each, in the order Zapier, Make, n8n. The finding that surprised us was not about features at all. It was that each platform's billing unit quietly rewrites how you are allowed to build. You do not pick a tool and then design a workflow. You pick a billing model and it designs the workflow for you.

The four workflows, and why we chose ones that fight back

Intake. A form submission creates a contact in the CRM, posts a formatted message to a Slack channel, and sends an acknowledgement email. Linear, three actions, no branching. The boring one, deliberately: this is what most people are actually buying.

Digest. Poll several RSS feeds every hour, drop anything already seen, and once a day assemble what is left into one email. This one has a loop and a memory, which is where things start to diverge.

Attachments. Watch a mailbox for invoices, pull the PDF, file it in cloud storage under a folder derived from the sender, and append a row to a spreadsheet. Binary data, conditional paths, and a name-matching step that gets things wrong often enough to matter.

Sync. A scheduled two-way reconciliation between two systems, paginated, with a rate limit that will bite you if you request too fast. The only workflow of the four that requires you to think about failure as a normal condition rather than an exception.

Intake behaved identically everywhere. The other three did not.

The billing unit is the design constraint

Here is the split, stated plainly, because it is the thing the marketing pages are structured to blur.

Platform	What gets billed	What that punishes
Zapier	Each successful action step (a "task"); triggers and filtered-out runs are not charged	Workflows with many small steps
Make	Every module call (an "operation"), including the trigger and each pass inside an iterator	Anything that processes a list
n8n Cloud	The whole workflow execution, regardless of how many nodes ran	Very frequent triggering

Billing units checked August 2026. We are deliberately not quoting plan prices here — those move, the units move far more slowly, and it is the unit that changes what you build.

Read those three rows again with the Digest workflow in mind. On Zapier, filtering early is free money: a trigger that fires two hundred times and a filter that stops a hundred and ninety of them costs you ten tasks. On Make, that same shape is expensive, because the trigger and the filter are themselves modules, and the iterator that walks a twenty-item feed charges twenty times for the steps inside it. So on Make you learn to do list work inside a single Aggregator or a chunk of custom JavaScript rather than as visible modules on the canvas. Which means the canvas — the thing you bought Make for — becomes less truthful the more you optimise.

n8n inverts it. Once an execution is the unit, node count stops mattering entirely, and you find yourself building the version you would have drawn on a whiteboard: explicit steps, one job each, easy to read. The pressure moves to trigger frequency instead. A workflow polling every minute is expensive on n8n Cloud and structurally cheap on Zapier if most polls end in a filter.

None of this is hidden, exactly. But it is presented as pricing, and it is not pricing. It is architecture. We had three visibly different implementations of the Digest workflow by the end, and not one of those differences came from a missing feature.

What the run log tells you at 03:40

Debugging is where the fortnight actually gets spent, and the three are not close.

n8n won this outright. Every execution is stored with the full input and output payload of every node, you can open any node and see the exact JSON it received, and you can re-run the workflow from that stored data without re-triggering the source. When the Attachments workflow filed three invoices under the wrong folder, we found the cause in about four minutes: the sender-name parsing had received a display name in one case and a bare address in the others, and it was right there in the node's input pane.

Make is second and would be first if the history retained more. The visual canvas doubles as the debugger — bubbles on the connections show how many items passed each hop, which makes "where did the twenty items become three" a glance rather than an investigation. But execution history is retained on a plan-dependent window, and the thing you want to inspect is frequently the thing that has aged out. Overnight failures are exactly the category most likely to be gone by the time you look.

Zapier is the weakest and it is not really the log's fault. The log is fine: task history, per-step data in and out, a replay button. The problem is that Zapier's linear model pushes complexity into places the log cannot see. When a Zap has a Code step or a Formatter chain doing the real work, the history shows you that step ran and what it returned, and the interesting part happened inside. We ended up writing our own logging into a spreadsheet, which is the universal signal that a platform's observability has run out. The basics of error handling in automations — retries, dead-letter paths, and alerting on silence rather than on errors — matter most on the platform that tells you least, and that is Zapier.

Where each one's core metaphor breaks

Make's canvas is genuinely the best way to understand a workflow you did not write — right up until roughly the twenty-module mark, at which point it becomes a diagram of a diagram. Routers nest, branches overlap, and the auto-layout does not save you. The Sync workflow, with pagination and two error paths, ended up as something we had to scroll around rather than read. Make's answer is to break it into sub-scenarios that call each other, which works, and which also means the single-canvas overview you were promised no longer exists.

Zapier's linear model has the opposite failure. It is legible forever, because there is nothing to lay out. But the moment a workflow needs to fan out and rejoin — do these three things, wait for all of them, then decide — you are either duplicating Zaps, chaining them via webhooks, or moving the logic into code. Paths help with branching; they do not help with converging. Zapier is the only one of the three where we hit a shape we could not express cleanly rather than a shape that was merely awkward.

n8n's breaking point is neither of these. It is the first time you need something the platform assumed you would know: that a node outputs an array of items and that a downstream node runs once per item unless told otherwise. Get that wrong and you get one email per feed entry instead of one digest. It is a five-minute lesson that costs an hour the first time.

Self-hosting is not free, it is a different invoice

The pitch for self-hosted n8n is that run-based billing disappears. That is true. What replaces it is a server, a database, a backup policy, credential encryption you now own, and an upgrade cadence that moves fast enough that ignoring it for six months is a decision with consequences. Ours ran happily on a small VPS for the fortnight, which proves nothing — two weeks is not where infrastructure fails.

The honest way to price it is in attention, not in hosting fees. If there is a person on your team who already maintains a server and would notice a container that stopped restarting, self-hosting is close to free. If there is not, you are buying a second job to avoid a subscription, and the subscription is cheaper. We went further into what that actually costs in two weeks running n8n on our own server, including the parts that only become obvious after the first upgrade.

The recommendation, by how much you actually run

Below a few dozen runs a day, with workflows that are three or four steps and no list processing, take Zapier. The per-task model is forgiving at that volume, setup is the fastest of the three, and the debugging weakness barely surfaces because there is not enough machinery to hide anything.

In the middle — hundreds of runs a day, real branching, workflows that other people need to understand without a handover meeting — take Make, and accept that you will be managing operation count as a design input. Budget the time to split large scenarios before the canvas becomes unreadable rather than after.

Above that, or as soon as any workflow touches lists of items on every run, take n8n. On Cloud if nobody wants to own infrastructure; self-hosted if someone already does. The execution-based unit means the cost curve stops tracking your workflow's complexity, and the run log is the only one of the three we never had to work around.

The trap in all of this is that these numbers move: a workflow that was ten runs a day when you built it is four hundred a year later, and the platform that was obviously right at the start is quietly the expensive one. Which is the argument for choosing on run volume you can project rather than on features you can count, and for revisiting the choice on a schedule — the same reasoning behind what makes an automation still work a month later.