Comparison

The same workflow cost 13 credits, 1 execution and 11 tasks

Three automation platforms, one identical job, one afternoon. The three numbers above describe the same work. They are not comparable, and nothing useful happens if you divide one by another.

What we ran

A single order-to-spreadsheet workflow: receive an order, fetch its line items, write one row per line, send one summary notification. We built it three times — once on each platform — and pointed all three at an endpoint we built and control, so every request was confirmed in our own server logs. Free plans, 2026-09-22.

The billing units, in each vendor’s own words

These units are not convertible. A credit, an execution and a task each measure a different thing, so 13, 1 and 11 must not be compared as numbers.

Why the numbers differ so much

Make and Pabbly bill something close to work done inside the scenario, so the count moves with the size of the order. n8n Cloud bills the run, so the count does not move at all. That single design difference is worth more than any headline price, because on two of the three platforms the number your customer controls — how many items they ordered — lands on your bill.

What counts as a credit in Make

We tested itIn our tested 10-line workflow, Make consumed 13 credits: 1 trigger, 1 fetch, 1 iterator and 10 per-line writes. The trigger and the iterator were billed alongside the external calls — every module in the scenario counted.

DocumentedMake’s help centre states that by default one operation equals one credit, that credits replaced operations as the name of the billing unit, and that existing plans and pricing were unchanged by the rename. (Make help centre, accessed 2026-09-24)

DocumentedCredit consumption is not uniform. The same documentation describes modules with fixed higher consumption, and AI and advanced apps with dynamic consumption that varies with factors such as tokens, file size, page count and processing time. (Make help centre, accessed 2026-09-24) — This is why our 13 is a measurement of one workflow, not a formula for yours.

Our workflow used standard modules only and contained no AI step. A scenario that uses them should not be expected to behave like ours. We did not find a date for the operations-to-credits rename on the page we checked, so we are not publishing one.

What counts as an execution on n8n Cloud

We tested itA 1-line order and a 10-line order each consumed 1 execution. A 7-node workflow and a 2-node workflow also each cost 1 execution, so neither order size nor node count moved the billed unit.

The self-hosted Community edition is unmetered. We have never run it, so everything we say about self-hosting is documentation, not testing.

What counts as a task on Pabbly

We tested itA 10-line fan-out cost 11 paid tasks and a 1-line order cost 2 — one paid task per line item plus one for the fetch. The webhook trigger and both iterators were charged nothing.

Does a failed run still cost you money?

This is the part almost nothing online answers, because answering it means deliberately breaking a working automation and counting. We did. The answer is vendor-specific.

We tested itMake: a completely failing 10-line run cost 4 credits against 13 for the identical successful run — it stopped at the first failing item rather than attempting the rest. Separately, a configuration error that never left Make still cost 4 credits.

We tested itMake: three automatic in-run retries of a failing HTTP step were billed as a single operation.

We tested itn8n Cloud: under a total destination outage it attempted all ten items, wrote nothing, and still consumed 1 execution — the same as a success.

We tested itPabbly: a completely failing 10-line run cost the same 11 paid tasks as a successful one and wrote nothing. Because automatic re-execution is on by default, it then retried itself about ten minutes later for a further 10 tasks. One broken order consumed 21 of our 100 free monthly tasks.

So: on all three platforms a failure cost us something. How much, and whether the platform then spends more on your behalf without telling you, differs by vendor. None of the three told anyone the run had failed.

What we observed, and what we are inferring

Observed: every number on this page is a count we took from a run we executed, against an endpoint whose logs we hold.

Inferred: that the per-line pattern continues at larger order sizes. We measured Make at 10 lines and Pabbly at 1 and 10; we did not test 50 or 500. Treat the shape as indicative and the counts as exact only at the sizes stated.

There is no winner here

Which model costs you less depends entirely on the shape of your work. If your orders routinely carry many line items, a per-work-unit model puts a number your customers control onto your bill. If your volume is low and your workflows are long, a per-run model can be the cheaper shape. Neither is better in the abstract, and anyone who tells you otherwise without stating the workload is guessing.

If you are still deciding whether this task is worth automating at all, work through the Automation Decision Sheet first — it is free, needs no email address, and frequently ends in “don’t”.