Automation Pricing Per Task and the Point Where Zapier Alternatives Start to Pay

The direct answer

A per-task bill has two inputs. How often a process runs, and how many billable units each run spends. The second one is yours to change, and it is usually the one doing the damage.

Before moving off Zapier, work out how many tasks a single run consumes and why. Actions repeated once per record, chains that could be one write, and replays that re-charge work already paid for all multiply the run count by something larger than it needs to be. Moving a wasteful workflow to a cheaper vendor buys a discount on the waste.

Once a workflow is as lean as it will get, the crossover is arithmetic. The numbers below let you do it with your own volumes.

Prices here were checked on 22 July 2026

Every figure was read from the vendor’s own pricing or documentation page on 22 July 2026, and each page is listed in the sources at the foot of this article. Automation pricing moves several times a year, plan names get retired, and allowances shift. Recheck against the live pages before you commit to anything.

Every figure below is in the currency the vendor quoted by default. Zapier and Make showed US dollars, n8n showed euros. Zapier’s pricing page does carry a currency selector that includes GBP, so a UK buyer can read sterling prices directly there rather than converting the dollar figures used here. Where you are converting, add card FX and, where it applies, VAT.

What the three vendors charge

Zapier

Zapier bills in tasks. The plans are Free, Professional, Team and Enterprise, and within Professional and Team you pick a monthly task allowance from a ladder. Annual billing is discounted, and the page states a 33% saving against paying monthly.

Annual-billing figures are the monthly equivalent of the yearly charge. Enterprise carries no displayed price and routes to sales.

Tasks are not the only thing that changes between plans. The Free plan is capped at two-step Zaps and checks trigger apps every 15 minutes. Professional polls every 2 minutes and Team every 1 minute, which is worth knowing before a latency complaint gets blamed on the wrong thing.

One figure in that table is worth pausing on. Zapier’s price per task falls as volume rises, from roughly $0.027 a task at the 750 tier to $0.0049 at 100,000, both on annual billing. Zapier does not penalise growth per unit. What grows is the absolute bill, and the absolute bill is the run count multiplied by the steps per run.

Make

Make bills in credits. Its documentation is explicit that “credits have replaced operations as the term for Make’s billing unit” with pricing unchanged, and that by default one operation equals one credit.

The volume selector on the page offers 10k, 20k, 40k, 80k, 150k, 300k, 500k, 750k, 1M and upward to 8M+. Prices above the 10,000-credit tier did not render in the page as we retrieved it, so those are not published here. Read them from the live selector. The page indicates annual billing saves 15% or more.

n8n

n8n bills in workflow executions. Its documentation defines one plainly: “An execution is a single run of a workflow.” Step count does not enter into it.

Monthly billing carries a premium over annual. For the Business plan, overage is priced at €4,000 for extra buckets of 300,000 executions. Enterprise overage is not published. There is no volume selector inside Starter or Pro, so between 10,000 and 40,000 executions a month the published ladder has exactly one rung and it costs €667.

Self-hosted Community Edition carries no licence fee. It is source-available rather than open source, under the Sustainable Use License version 1.0. The grant covers use, copying, distribution and derivative works for “your own internal business purposes or for non-commercial or personal use”. Distribution is permitted only free of charge and for non-commercial purposes, you may not charge others for the software, and files whose names contain .ee. are excluded and require a separate n8n Enterprise License.

What consumes an allowance

This is where the three diverge most, and where a per-run estimate built from intuition goes wrong.

Zapier. Its help article “How is task usage measured in Zapier?” lists what counts as all successful action steps, any successful step inside an error handler path, previously successful steps that run again when you replay an entire Zap run, action steps in sub-Zaps including the Call a Sub-Zap and Return From a Sub-Zap actions, and a search action configured to proceed when nothing is found.

What does not count is longer and more useful. All trigger steps. Any Filter or Paths step. All action steps that error or halt. All steps that never run because a filter, a path condition or an earlier error stopped them. The Start a Sub-Zap trigger. Steps for Zapier Tables and Zapier Forms. And steps from Formatter, Delay, Looping, the Sub-Zap app, Digest, Zapier Manager and Storage.

A handful of things bill at a different rate. AI by Zapier depends on the model tier selected, Code by Zapier uses one task at standard runtime and more at extended runtime, Lead Router counts five tasks per successfully routed lead, and Zapier MCP counts two tasks per successful tool call.

That list contains an inconvenient correction. The widely repeated advice that polling triggers burn through your task allowance is wrong for Zapier. Triggers never consume tasks, however often they poll, and a run stopped by a filter costs nothing either. Zapier’s multiplier is successful action steps per run, at the rates listed above.

Make. An operation is defined as “a single module run to process data or check for new data”. Regular modules consume one operation per bundle, so a module handed ten bundles runs ten times and costs ten. Trigger modules are the exception and “only run once to check for or retrieve data, regardless of the number of bundles returned”. Make’s own worked example has a trigger returning ten form responses and three downstream modules, totalling 31 operations for one scenario run.

The Make documentation we read did not state whether a scheduled check that returns nothing still consumes an operation, although the “check for new data” wording in the definition implies it does. It also did not state how errors, retries or bundles removed by a filter are treated. Those are the three questions worth putting to Make in writing before you budget on an assumption, because on a per-bundle model the answers change the total materially.

n8n. One execution per workflow run, independent of step count, and only production runs count. The documentation is specific about the edge cases. A Schedule Trigger counts “one execution every time the node fires, regardless of outcome”, so a scheduled run that fails still spends one. A polling trigger “only counts when it finds new data”, so empty checks are free, which is the opposite of Make. Webhook triggers count one per inbound request that activates them, and requests malformed enough to be rejected before the workflow starts do not count. Manual runs from the editor, error workflows, and sub-workflow runs called with Execute Sub-workflow are all excluded, with only the parent execution counted.

The same workflow at three volumes

The following is hypothetical, constructed for the arithmetic. One trigger and four action steps, one record per run, three volumes.

Three things fall out of it.

At 500 tasks a month, nothing here is worth moving. Cheapest to dearest is roughly $9 against $20, so the spread is about $11 a month and any migration costs more than a year of the difference.

At 5,000 tasks a month the spread is roughly $80 a month, or under $1,000 a year. That is a real number and still a small one against rebuilding connectors, retraining whoever maintains the flow, and carrying the risk of a botched cutover. It is roughly one to two hours of engineering time a month, which is the correct comparison to make.

At 50,000 tasks a month, Zapier’s $289 looks expensive beside a self-hosted instance and cheap beside n8n’s published Business rung at €667. That is the whole point. “Zapier is expensive at scale” only means something once you name the alternative you are measuring against.

Where the multiplier comes from

Four patterns account for most of the gap between the units a workflow spends and the units it needs.

Actions repeated per record. Take a hypothetical order with twenty line items and two actions per item. That is forty tasks plus the two fixed steps, so 42 tasks per order. A thousand orders a month is 42,000 tasks, landing on the 50,000 tier at $289 a month on annual billing. Send the line items as one payload to an endpoint that accepts them in a single call and the same order costs three tasks. A thousand orders becomes 3,000 tasks, the 5,000 tier, $89 a month. Identical work, identical volume, one third of the price. The Looping step itself is free on Zapier; the actions inside it are not.

Chains that could be one write. Look up a record, set a field, update the record, then update it again with a status. Formatter and Delay steps are free on Zapier, so part of a long chain costs nothing already. Every genuine write does count, and merging three writes to the same record into one is a direct cut in tasks with no change in behaviour.

Filters placed after the work. On Zapier a filter costs nothing and stops the run, so a filter is only expensive when it sits downstream of actions it should have prevented. On Make the arithmetic is different, because every module that ran before the filter is an operation you have already spent. Move the condition as close to the trigger as the data allows.

Replays and backfills. Replaying an entire Zap run re-charges the steps that already succeeded. On a one-off backfill of a few thousand records that can double the month.

None of these need a new vendor. They need somebody to open the run history and count. That is the same discipline as deciding which processes to automate at all, applied one layer down, and it is faster than a migration by a wide margin.

The real cost of self-hosting

Apefo Ltd runs its own hosting infrastructure under the YNVAR brand, so this section comes from operating servers rather than from reading a pricing page.

A self-hosted n8n Community Edition instance has no licence fee. Everything else is still there.

• The server. Take the figure from your own provider. The £25 a month used below is an assumption for the arithmetic and should be replaced with a real quote. So are the two hours of monthly maintenance and the £60 hourly internal cost: between them they carry £120 of the £145 total, so your own figures will move the answer more than anything else on this page.
• A database that is not the default. Postgres rather than the bundled SQLite once volume is real, plus somewhere for it to live and something backing it up.
• Restart on failure. A container that dies at 02:00 and stays dead until somebody opens a laptop is a worse outage than any task limit you were trying to escape.
• Disk. n8n prunes execution data by default, at 336 hours and a maximum of 10,000 stored executions, controlled by EXECUTIONS_DATA_MAX_AGE and EXECUTIONS_DATA_PRUNE_MAX_COUNT. Raise those to keep an audit trail and the database grows to match. Disable pruning and plan for it.
• TLS renewal and version upgrades, including reading release notes before applying them rather than after.
• Backups you have restored at least once. An untested backup is a belief.
• A named person who is reachable when it stops. This is the line item that gets left out, and the one that decides whether self-hosting was a good idea.

Time, and not the server, is the cost.

The gap is real and it is not transformative. At three hours of maintenance a month the self-hosted total reaches £205, which is still nominally under Zapier’s $289 but close enough that the choice stops being about money. It tips the other way somewhere above four hours, sooner once you apply an exchange rate, and sooner again if there is no engineer already on the payroll and the hours have to be bought in. The saving is genuine when you already run servers and one more small service is a marginal addition to work you do anyway. It is imaginary when self-hosting means one person adding an unfamiliar production system to their evenings.

Two further points belong here. n8n’s Business plan is a self-hosted deployment at €667 a month billed annually, so self-hosting with SSO and the enterprise feature set is not the free path. And the Sustainable Use License covers your own internal business purposes, which is worth reading carefully if the plan was ever to host instances on behalf of clients.

Working out your own crossover

Five numbers, and you can have all of them inside an hour.

1. Runs per month for each workflow, taken from the platform’s own execution history rather than from memory.
2. Billable units per run, counted from one real run in the log rather than estimated from the canvas.
3. Units per month, the first multiplied by the second and summed, plus headroom for the month with the spike in it.
4. The tier that number lands on, read from the live pricing page today.
5. The lowest units-per-run figure you could reach by redesign, and the tier that lands on.

If steps 4 and 5 land on the same tier, redesign saves nothing this year and you can move straight to comparing vendors. If they land two tiers apart, do the redesign first. It is cheaper, it is reversible, and it shrinks any later migration, because a workflow with fewer steps has fewer connectors to rebuild.

Then compare per run rather than per unit. A task, a credit and an execution are three different things and their headline prices are not comparable. Add the cost of moving. Rebuilding a connector-heavy workflow is a real project, and the systems it has to touch decide most of that cost.

When staying on Zapier is the right call

Zapier’s behaviour at high volume is a property of a per-action pricing model, and per unit that model gets cheaper as you grow. Whether it is expensive for you depends entirely on what the alternative costs in engineering time, and engineering time is the more expensive input for most businesses of this size.

Stay where you are when there is no in-house engineer to own an alternative, when the apps you depend on are ones Zapier connects natively and a move would mean hand-built HTTP calls, when the total bill is a few hundred a month and the entire achievable saving is smaller than the migration, or when having a vendor to escalate to is worth the difference on its own.

Look harder at moving when one high-volume workflow dominates the bill and would be simple to rebuild, when you already run infrastructure and one more service is a marginal cost, or when you need something the platform cannot offer, such as running inside your own network or keeping data on hardware you control.

The middle option gets overlooked. Split the estate. Leave the low-volume, high-connector-count workflows where they are, and move only the one generating most of the units. That keeps what the platform is genuinely good at and removes the line that made you start reading pricing pages. How the moved workflow is built and maintained afterwards will matter more to you in a year than which platform runs it.

What it comes down to

Per-task pricing behaves well until a badly shaped workflow multiplies the unit count, at which point it behaves exactly as designed. Read the run log, count the units, remove the ones nobody needs, and recalculate. If the number still hurts afterwards, the vendor comparison has become a real comparison and the arithmetic above will settle it in an afternoon.

Then recheck the prices. Everything here was true on 22 July 2026, and some of it will not be true next quarter.