Comparison
Do failed automation runs cost money?
Yes. On all three platforms we tested, a run that failed and wrote nothing still consumed billable usage. But the failed run itself was rarely the expensive part — on one platform the automatic retry cost more than the original failure, and told nobody.
No link on this page is an affiliate link. We are in the programme below, so we could earn a commission elsewhere on this site — but not from anything on this page. We recommend free tools where they are the better answer, including ones that earn us nothing.
- Make.com: 35% of subscription payments for 12 months; extra-operation purchases do not earn commission (terms verified 2026-09-24)
The short answer, by platform
| Platform | Successful 10-line run | Same run, failing completely | What happened next |
|---|---|---|---|
| Make | 13 credits | 4 credits — cheaper, because it stopped at the first failing item | No automatic re-execution. Recovery was manual. |
| n8n Cloud | 1 execution | 1 execution — identical to a success | No automatic re-execution in a verified 10 min 56 s window. |
| Pabbly | 11 paid tasks | 11 paid tasks — identical to a success, and it wrote nothing | Automatic re-execution fired and cost 10 more tasks. |
Those three columns are not convertible into one another. A credit, an execution and a task measure different things — see credits, executions and tasks for why dividing one by another produces a meaningless number.
What we ran, and how we broke it
One order-to-spreadsheet workflow: receive an order, fetch its line items, write one row per line. 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. Then we made that endpoint fail on purpose and ran the identical job again. Free plans, 2026-09-22.
Make: the failure was cheaper than the success
We tested itIn our tested 10-line workflow a completely failing run cost 4 credits against 13 for the identical successful run — Make stopped at the first failing item rather than attempting the rest.
We tested itA run that failed on a duplicate cost the same as a successful run, and a configuration error that never left Make still cost 4 credits.
We tested itIn our test, three automatic in-run retries of a failing HTTP step were billed as a single operation.
That last point is the one most likely to surprise people: in this test the in-run retries were not separately billed. The cost came from the modules that ran before the failure, not from the retrying. If you are budgeting for Make specifically, where our 13 credits went breaks the successful run down step by step.
We tested itNo automatic re-execution occurred after our deterministic failure, and the Incomplete Executions queue was empty — that storage is off by default. Recovery was manual.
n8n Cloud: a failure cost exactly what a success cost
We tested itUnder a total destination outage it attempted all 10 items, wrote nothing, and still consumed 1 execution — the same as a success. No automatic re-execution occurred in a verified 10 minute 56 second window.
This follows from the unit rather than from any failure policy: n8n Cloud bills a run of the workflow, not the steps inside it, so a run that achieves nothing costs the same as a run that does everything.
We tested itNo alert reached anyone by default. Per-node retry is off by default and we did not enable it, so retry behaviour is untested.
Pabbly: the retry cost more than the failure
We tested itA completely failing 10-line run cost the same 11 paid tasks as a successful one and wrote nothing.
We tested itBecause automatic re-execution is on by default, that failure then cost a further 10 paid tasks without notifying anyone. One broken order consumed 21 of our 100 free monthly tasks in about ten minutes.
Pabbly was the only platform of the three that recovered on its own, which is genuinely useful when the destination is briefly down. It is also the behaviour that makes a persistent failure expensive: a run that cannot succeed is retried at full price, and nothing tells you it is happening. For how Pabbly counts a task in the first place — and which steps it does not charge for — see our Pabbly tasks guide.
What this means for your own numbers
- Budget for failures, not just for successes. On the two platforms where a failure cost the same as a success, a broken week costs what a working week costs.
- Find out whether automatic retry is on. It was on by default on Pabbly and off by default on n8n in our tests. That single setting changed the cost of one broken order by a factor of two.
- Check whether anything tells you. None of the three notified anyone by default in our tests. The bill is not the first thing that should tell you an automation is broken — see when an automation breaks and tells nobody.
- Work out whether your usage scales with rows. Make and Pabbly billed per line item; n8n Cloud did not. Ten-line orders and one-line orders are not the same problem on every platform.
What we did not test
Limitations and failure cases
- The three builds were not identical. Only n8n's version aggregated the rows and sent a summary notification; the Make and Pabbly versions stopped at the row writes. Build time is not comparable for the same reason.
- We have not run Zapier. It is not in the table above and we make no claim about how it bills a failed task.
- We have not run n8n's self-hosted Community edition. Every n8n figure here comes from the Cloud trial.
- n8n's per-node retry is off by default and we did not switch it on, so we cannot tell you what an n8n retry costs.
- These are single controlled runs of one workflow on free plans on 2026-09-22, not an average across accounts, plans or time.
- Vendors change billing behaviour. Treat every number here as dated evidence rather than a permanent property of the product.
Make’s own help centre states that consumption is not uniform across modules —
Documentedby default one operation equals one credit, but AI and advanced modules can consume differently. (Make help centre, accessed 2026-09-24)
Our 13-credit figure describes one workflow built from standard modules, not every workflow.Where to go next
- Credits, executions and tasks: the same workflow, three different bills — what you are charged for when the run succeeds.
- The failure-handling workflow we built and deliberately broke — the design-level evidence behind retries and silent failure.
- The Automation Decision Sheet — the questions to answer before you build, including what happens when it breaks. No email required.