Zapier and Make task limits: what a social automation workflow actually burns per run

An automation that posts one piece of content to three social networks and logs the result to a spreadsheet does not spend one unit of usage per run. It spends several, and the gap between what someone budgets for and what the vendor actually bills is what produces a task limit warning in the middle of the month, usually on a plan picked without doing this arithmetic first.

The workflow everyone builds first

The automation that shows up first, in Zapier or in Make, almost always has the same shape. A new piece of content is published or detected. That single event fans out into several downstream actions: post to network one, post to network two, post to network three, then write a row to a tracking spreadsheet. Step by step, that is one trigger and four action steps.

Which of those five steps is free and which is billed depends on the vendor’s own definition, and the two vendors do not agree. In Zapier, the trigger step never counts against a task limit, and every action step that completes successfully does. In Make, the trigger module does use an operation each time it runs.

What actually gets counted

Zapier’s help center defines a task narrowly. A task is counted only when an action step completes successfully. The trigger step never counts, in any Zap. The same article lists built in step types that do not count even when they run: Filter by Zapier, Formatter by Zapier, and Paths steps, plus the Delay, Looping, Sub-Zap, Digest, Zapier Manager, and Storage apps, along with Zapier Tables and Forms steps.

Make’s help center uses different vocabulary and a different rule for triggers. Its credits article states that credits replaced operations as the term for Make’s billing unit. For non-AI apps, 1 operation equals 1 credit. Its operations article defines an operation as a single module run to process data or check for new data. Most modules run once for each bundle of data they receive, so a module handling 3 items uses 3 operations. Trigger modules are the stated exception: they run once to check for or retrieve data, and that check is 1 operation regardless of how many bundles come back.

Both vendors meter per action performed, not per automation run, so more steps means proportionally more usage.

The arithmetic: pricing the auto-post-and-log workflow

One constraint comes before the totals. Zapier’s Free plan is limited to two-step Zap workflows, so the workflow described here, a trigger plus four downstream actions, cannot be built on Free at all. The task figures below show where the volume would sit against a 100-task ceiling, not a plan this workflow can actually use.

In Zapier, the trigger costs nothing. Three posting actions cost one task each at the standard rate, and the action that writes a spreadsheet row costs one more. That is four tasks for one successful run, using only plain repost and logging steps.

That count changes the moment a step costs more than the standard rate. Zapier’s pricing FAQ states that some apps or actions may use more than one task when completed successfully. Its usage rates page lists a Zapier MCP tool call at 2 tasks per successful call, and AI by Zapier steps are priced by the model tier selected. A version of this workflow that adds an AI step to rewrite the caption before posting is no longer a four task run. It is four tasks plus whatever that step adds.

In Make, the same workflow is different because the trigger is counted. Suppose the scenario runs and finds one new post. The trigger module uses 1 operation, each of the three posting modules runs once for that one bundle, and the sheet module runs once. That is 5 operations, which is 5 credits at the default rate for non-AI apps. If a run picks up two new posts at once, each downstream module runs twice, so the scenario costs 1 plus 8, or 9. Make’s operations article shows the same multiplying effect with a worked example of 1 trigger operation plus 30 downstream operations, 31 in total.

The monthly math follows once the per-run count is fixed. At one run per weekday, roughly 22 runs a month, four Zapier tasks per run comes to 88 tasks a month. That sits 12 tasks under Zapier’s Free ceiling of 100 tasks, before a fourth network, an AI step, or anything else adds to the count, and the step limit still rules the plan out. The same 22 runs at 5 Make credits each is 110 credits a month, before any run that picks up more than one post.

Where teams actually get surprised

  • Retries are not the silent cost most people assume. Zapier’s pricing FAQ states it directly: if an action isn’t successfully completed, it doesn’t count against the task limit. A failed step that Zapier retries consumes a task only on the run where it actually completes.
  • The real silent cost is workflow growth. Adding a fourth social network, a Slack notification, or a write to a Zapier Table onto the same Zap adds one task to every successful run from that point on. That compounds quietly until someone adds up the monthly total.
  • Batches multiply in Make. Because each downstream module runs once per bundle, a trigger that returns several items at once raises the cost of every module after it.
  • The step count can be a harder wall than the task count. Zapier’s Free plan allows two-step Zaps regardless of how many tasks remain. The five-step shape described here needs the Professional plan, which Zapier’s pricing page lists from $19.99 per month. That is separate from the task ceiling.

Counting your own workflow before it runs out

The method needs a list, not a tool. Write down every step in the workflow. In Zapier, drop the trigger and count one task for each action step at the standard rate, then remove the steps on Zapier’s published exception list: Filter, Paths, Formatter, Delay, Looping, Sub-Zap, Digest, Zapier Manager, Storage, Tables, and Forms. In Make, count the trigger as one operation per check and every other module as one operation per bundle it processes, then check Make’s credits article for modules that cost more than the default. What remains is the real per-run cost.

The correction most people skip is multiplying that per-run count by actual runs per month, not by the number of Zaps or scenarios that exist. One Zap that runs 30 times a month costs 30 times its per-run count.

The decision point worth naming: once the monthly total lands within roughly 20 percent of the plan’s ceiling, that is not enough headroom to add one more network, one more notification step, or one more field to the sheet before the next billing cycle closes. Trim a step, cut run frequency, or move up a tier deliberately, before a limit warning decides for you.

FAQ

Does the trigger step of a Zap count as a task?

No. Zapier’s help center article on task usage states that tasks are counted only on successful action completion and that trigger steps never count.

If a Zap step fails and Zapier retries it, does that use two tasks?

No. Zapier’s pricing FAQ states that if an action isn’t successfully completed, it doesn’t count against the task limit.

Are Make’s operations the same thing as its credits?

They are related but not identical terms. Make’s credits article says credits replaced operations as the term for its billing unit, and that for non-AI apps 1 operation equals 1 credit. It adds that credits track spending while operations show what happened in a run.

Can a single AI or MCP step in a Zap cost more than one task?

Yes. Zapier’s usage rates page lists a Zapier MCP tool call at 2 tasks per call, and AI by Zapier is priced by the model tier selected, which breaks the one step, one task assumption for an AI formatting step.

Can a five-step automation be built on Zapier’s Free plan even with enough tasks left?

No. Zapier’s pricing page limits Free to two-step Zap workflows regardless of task balance, so a trigger plus four action steps needs the Professional plan.

Sources

Prices and plan terms verified 2026-09-25 from the vendors’ own pages listed above. This post is not Watchdog data and is not on the re-verification schedule, so figures may have changed since that date. followed is published by the team behind RecurPost.

Back to Blog

Scroll to Top