The hidden cost of per-task pricing at volume
Per-task pricing becomes expensive when monthly runs multiply by several billable actions, retries, iterators, or premium-action rates. If your bill is climbing, measure billable actions per completed run, reduce that number first, and keep important business logic outside platform-specific workflow steps so you can change the billing model later.
Do not move platforms merely because the run count has reached 50,000. A simple workflow may remain economical under per-task pricing, especially when volume discounts and non-billable internal steps flatten the curve. The warning sign is not volume alone. It is a rising number of billable actions for each useful piece of work.
What is the hidden multiplication in per-task pricing?
The basic model is:
monthly billable usage = monthly runs × billable actions per run × action-specific multiplier
Zapier generally counts each successful standard action as a task. Make generally consumes a credit when a module performs an action. Some AI, code, routing, and premium actions can use different rates, so the last part of the formula cannot always be treated as one.
That distinction between a run and an action is where forecasts often go wrong. A run might receive a record, search for a customer, update that customer, create an invoice, and send a notification. The business sees one completed record. The billing system may see several actions.
| Monthly runs | One billable action per run | Three billable actions per run | Ten billable actions per run |
|---|---|---|---|
| 500 | 500 units | 1,500 units | 5,000 units |
| 5,000 | 5,000 units | 15,000 units | 50,000 units |
| 50,000 | 50,000 units | 150,000 units | 500,000 units |
These are illustrative demand figures as of September 14, 2026, derived from the workload formula rather than quoted vendor allowances. Actual usage changes with free built-ins, retries, iterators, batching, filtered events, AI features, and action-specific multipliers. The platforms also do not count every visible workflow step in the same way. The underlying action models are documented by Zapier and Make.
The steepest curve in the table is not caused by 50,000 runs on its own. It comes from combining 50,000 runs with ten billable actions. Reducing that workflow to three billable actions cuts the modeled demand from 500,000 to 150,000 units per month as of September 14, 2026. That is why action count should be inspected before the platform is replaced.
Does every visible workflow step increase the bill?
No. This is the strongest reason not to assume that per-task pricing always becomes painful at volume.
As documented on September 14, 2026, Zapier does not charge tasks for triggers, unsuccessful actions, or several built-in tools, including Filters, Paths, Formatter, Delay, Looping, Sub-Zaps, Digests, Storage, Tables, and Forms. A large visual workflow could therefore perform extensive internal routing and formatting while consuming one task for its one successful external action.
Make can produce a different curve. Its credit documentation says that searching, reading, creating, updating, deleting, transforming, aggregating, and iterating can consume credits. An iterator can turn one incoming collection into many downstream module operations. Batching or aggregation can sometimes move the curve in the other direction.
The practical measurement is therefore not “How many boxes are on the screen?” It is “How many billable units did this workflow consume for each completed business outcome?” Pull that number from real history over a representative period. Separate ordinary runs from exceptions, retries, and unusually large batches so one blended average does not hide the cause.
Do volume discounts make the problem go away?
They can make it smaller. Make provides a useful example of a curve that becomes cheaper per included unit as volume rises.
| Published anchor | Price as of September 14, 2026 | Included volume | Derived cost per included unit |
|---|---|---|---|
| Make Core selection | $12 per month | 10,000 credits per month | $0.0012 |
| Make Core worked example | $113.85 | 150,000 credits per month | $0.000759 |
Between those two published anchors, included volume rises 15 times while price rises about 9.49 times as of September 14, 2026. That is real evidence against treating every additional action as if it retained the entry-tier unit price.
The comparison has important limits. The $12 figure came from Make’s main pricing page, but the retrieved page did not unambiguously identify the billing-cycle control that produced it. The $113.85 figure appears in an official subscription example rather than a complete pricing table. The two anchors may reflect different billing-cycle selections, and unused credits expire. They demonstrate a declining unit curve, not a guaranteed quote for a particular account.
Zapier also provides lower unit costs at higher tiers, so the currently documented $129 per month for 10,000 tasks as of September 14, 2026 should not be extrapolated linearly. Exact current public prices at 50,000, 100,000, 150,000, and 500,000 Zapier tasks were not available in the retrieved pricing material. Exact Make prices for several corresponding high-volume selections were also not captured. Get the actual tier or account quote rather than extending either entry-level number.
When do overages make the curve harder to control?
Overages matter because the next task can cost more than a task included in the subscription. Zapier says pay-per-task usage is charged at a higher rate than base subscription tasks. Its exact dollar rate depends on the account plan and billing cycle and is shown in account billing settings rather than as one public rate.
As of August 15, 2026, Zapier permits total usage up to three times the subscribed task allocation, including the base allowance. Its documented example allows a 750-task plan to reach 2,250 total tasks: 750 included tasks plus 1,500 pay-per-task tasks. Workflows stop when that total limit is reached.
That creates two separate questions. First, what will the extra usage cost? Second, what happens to the process at the usage ceiling? The first requires the account-specific rate. The second is an operating constraint even when the business is willing to pay.
The response is not automatically to buy a larger plan. First identify whether duplicate writes, repeated searches, item-by-item processing, or avoidable retries are consuming the allowance. “Rate limits, retries and the parts nobody demos” will cover the operational mechanics separately; the pricing point here is that repeated actions remain part of the cost curve.
Would execution-based or compute-based pricing be cheaper?
Sometimes, but neither model removes variable cost. It changes what causes the cost.
n8n charges for complete workflow executions rather than each step. On the tiers displayed September 14, 2026, its hosted Starter plan was €20 per month for 2,500 executions and its hosted Pro plan was €50 per month for 10,000 executions, both expressed as annual-billing equivalents. Each execution can contain unlimited steps.
That model deserves attention when a run contains many necessary actions. It is not proof of a lower total cost. The displayed n8n Business offer was €667 per month for 40,000 executions as of September 14, 2026, billed annually and self-hosted. It includes governance and scaling features, while infrastructure and operating labor are additional. It is not a clean price-only comparison with the hosted plans or with managed per-task services.
Pipedream uses another model: one credit per 30 seconds of compute at 256 MB for each workflow segment as of September 14, 2026. More memory, longer runtime, branches, delays, and additional segments increase consumption. A short workflow with many steps can benefit, while a long or memory-heavy job takes on a different cost risk.
Per-task billing can be the more predictable choice for a stable workflow with one known external write. Compute billing can be easier to justify when step count is high but runtime stays controlled. The relevant comparison is the full process under both billing units, including the labor and infrastructure required to operate it. No neutral current benchmark was found that assigns a universal dollar value to migration and maintenance labor.
The broader platform comparison belongs in “n8n vs Make vs Zapier — and why we don't have a favourite.” The five-year difference between a subscription and a separate build belongs in “Build once or subscribe forever — the five-year maths.”
What does portable workflow design actually mean?
Exporting a workflow is not the same as making it portable. Zapier supports workflow JSON import and export on Team and Enterprise accounts as of September 14, 2026, but those files are designed to move workflows between Zapier accounts. Connections still require testing or reconnection. Connection inventories do not contain credentials or API keys, and exported workflows do not include their version history.
No universal cross-platform workflow format was verified. A vendor JSON export is useful for backup or account transfer, but it is not a neutral executable definition that can be loaded into another automation product.
Our assessment is that portable design should separate the parts that describe the business from the parts that operate a particular platform:
- Business rules: Document conditions, calculations, required approvals, and exception behavior independently of named workflow nodes.
- Schemas: Define the expected input and output fields so a replacement workflow does not have to infer them from old mappings.
- State: Keep durable status, identifiers, and processing checkpoints somewhere that is not meaningful only inside one workflow.
- Tests: Preserve representative inputs and expected outputs so migrated logic can be checked before it handles live work.
- Interfaces: Put complex rules behind a documented API or webhook where practical, then let the automation platform trigger and coordinate them.
The last pattern is supported by the fact that Zapier can send standard HTTP webhook requests with raw JSON or XML. It does require more deliberate design than placing every condition directly into vendor-specific nodes. That extra work is justified when the rules are valuable, frequently changed, or likely to outlive the current billing model. It is probably unnecessary for a small, stable connection with little logic.
Source control can improve handover, but it can also affect the plan decision. n8n’s Git-based source-control environments are available on Business and Enterprise plans and support separate development and production instances and branches. Portability has to be evaluated alongside the tier needed to operate it.
What should you do when the bill is already climbing?
- Measure completed outcomes. Count the invoices processed, records synchronized, or cases completed during the billing period.
- Measure billable usage. Separate ordinary actions from retries, iterations, premium actions, and exceptions.
- Calculate units per outcome. This exposes whether growth comes from more useful work or more actions for the same work.
- Reduce the action count. Remove repeated lookups, batch items where the workflow permits it, and use non-billable internal logic where the platform documents it.
- Price the next real tier. Use the account’s current quote and overage rate rather than extrapolating from a starting plan.
- Model one alternative billing unit. Compare the same workflow under execution-based or compute-based pricing, including infrastructure and operating work.
- Separate durable logic before migrating. Write down rules, schemas, state, and expected outputs before rebuilding the orchestration.
If the workflow is simple and the effective cost per completed outcome remains acceptable, stay on the current platform. Automation is the wrong answer when the underlying process is unstable or does not produce enough value to justify maintaining it; “When automation is the wrong answer” covers that decision.
If the workflow needs many paid actions and its volume is predictable, compare execution-based billing. If its rules matter beyond the present tool, make those rules portable before the pricing curve forces a rushed migration.
Book the call. Bring one recent billing period, the workflow history, and the number of completed business outcomes. We will map the current cost curve and identify which actions are worth redesigning.
