Why your Zapier tasks run out, and how to cut the bill

Usually because a few Zaps are paying for work they did not need to do. Zapier counts one task for each action step that runs successfully, and nothing for the trigger, the polling, filters, Paths conditions or Formatter steps. That makes the bill a count of action steps that ran. The common leaks are a search or update that runs before the filter that would have stopped the Zap, a trigger that fires on every edit when only one change matters, a loop that repeats actions for every item, a whole Zap run replayed when only one step failed, and, since 15 June 2026, AI by Zapier steps on a model tier that charges several tasks a run.

On Zapier, most of the fixes cost nothing, because the steps that do the fixing are free. A filter straight after the trigger can bring the cost of an irrelevant run to zero. A bigger plan buys more tasks to spend on the same waste. Moving to Make can make a polling Zap more expensive, because Make bills the polls Zapier gives away. Find the one or two Zaps carrying the bill, change their order and their trigger, then decide whether the platform is still the problem.

Zapier's definition is short: a task is an action step that runs successfully. Everything else follows from that. The trigger is not an action, so it never counts, and nor does any check a polling trigger makes for new data. Steps that error or halt do not count. Filter, Paths and Formatter steps no longer count either, and Zapier's task-usage page lists Delay, Looping, Digest and Storage among the built-in steps that are also free. The table sets out the cases that matter for a bill.

This is the main difference from Make, where a trigger's check counts as a credit and a slower schedule is often the first fix. On Zapier, slowing a poll saves nothing. The cost sits entirely in the actions, so that is where to look. Our Make vs Zapier vs n8n comparison sets the three billing units side by side, and our Make.com credits article covers the same problem on Make.

Six patterns account for most bills that grow faster than the business. None of them is visible from the Zap list. All of them show up in Zap history.

Paid steps that run before the filter

A Zap often needs one piece of information the trigger does not carry, so someone adds a lookup, then a filter on the result. Every run now pays for the lookup, including the runs the filter then stops. The same happens with an update step placed early so that a later step can use its output. The deal example above is this pattern, and it is the most common reason two Zaps doing similar jobs cost very different amounts.

Triggers that fire on every update

Triggers like updated row, updated record or any property change start a run for every edit, including edits by people tidying a field the Zap does not care about. The trigger is free, but any action before the filter is not. A worse version is a Zap that updates the record that triggered it. The update fires the trigger again, the Zap runs again, and if the second run writes too, the loop continues until something stops it. Each pass pays for its actions.

Loops, line items and per-row writes

The Looping step itself is free, and every action after it counts once per item. Zapier's own example is a loop that runs 500 times making a single action after it use 500 tasks. The expensive shape is a loop over a whole sheet or a whole order with two or three actions inside it, when only a few items needed the work. As an illustration, 200 rows with two actions each is about 400 tasks a run. If the list is filtered to the five rows that changed, it is ten.

Scheduled Zaps that do work on every run

A Zap started by Schedule by Zapier has a free trigger, and then runs its actions every time it fires, whether or not there is anything to do. An hourly Zap that reads a sheet and posts a summary uses two tasks an hour, about 1,440 a month on a 30-day month, even in the weeks when the summary is empty. The fix is a search that stops the Zap when nothing is found, or a filter on an empty result, so the quiet hours cost nothing.

Replays, error paths and Zaps nobody switched off

Replaying a whole Zap run is treated as a new run, so steps that already succeeded are counted again, and any duplicate records they create are yours to clean up. Error-handling paths are good practice, and their successful steps count, so a long error path makes every failure more expensive. The quietest leak is duplication: an old Zap and its replacement both switched on, or two people's versions of the same automation running on the same trigger. Our article on why automations break covers the duplicate records. The point here is that each copy is billed.

AI, Code and MCP steps

Three newer step types do not follow the one-task-per-step rule. AI by Zapier steps are priced by model tier, and each tool call they make is charged at the tier's rate again. Code by Zapier steps use a task to run and can use more when they run past the plan's standard runtime. Calls to Zapier through its MCP server use two tasks each, from the same allowance as your Zaps. Since an AI assistant connected over MCP may make several tool calls to answer one request, its usage can grow faster than anyone expected.

From 15 June 2026, AI by Zapier steps are priced by model tier. Zapier's tier page lists Standard at the base rate, Advanced at three times it and Premium at five times, with Standard not able to use tools. A step's cost per run is its tier rate, plus the tier rate again for each tool call. On Zapier's own arithmetic, a Premium step that makes two tool calls uses 15 tasks a run. Zapier also pauses a step that reaches 75 tasks in a single run and asks for approval before it continues.

Zapier's own pages disagree about which tier a new step starts on, but neither names the cheapest one. Open every AI step in your busiest Zaps and check its tier. A step that classifies an email into one of four labels, or pulls three fields out of a form, rarely needs tools or the top tier.

• Test the cheapest tier that could work. Run a test set of your own inputs through Standard. If it passes, a higher tier is spending tasks on capability you are not using. If it fails, the saving is not worth the errors it lets through.
• Count the tool calls. Each one costs the step's rate again, so a step that looks up a record, checks a calendar and writes a note is four charges, not one. Where the lookup can be an ordinary search step before the AI step, it costs one task instead of a tier multiple.
• Do not run the step on unchanged input. Store the result against the record with Storage by Zapier, which does not use tasks, and skip the AI step when the input has not changed.
• Unlike Make's AI Provider, which charges by tokens, Zapier charges AI steps per run and per tool call. Shortening the output does not change the count. Fewer runs, fewer tool calls and a lower tier do.
• Measure rather than assume. Compare the task usage of your AI steps before and after 15 June 2026. That comparison is your real figure.

It depends on whether pay-per-task billing is switched on for your account. With it on, Zaps keep running past the plan's included tasks and the extra tasks are billed, up to a ceiling that Zapier's help centre currently puts at three times the plan's task limit. Check the rate on your own billing page, because Zapier's pages describe it differently. With it off, Zapier holds new Zap runs until the billing cycle resets. Held runs are not lost and can be replayed after the reset, after an upgrade or after pay-per-task billing is switched on, and replaying them uses tasks.

Held is not the same as handled. A lead that arrived on the 24th sits in a held run until someone replays it, and the notice that runs are being held may go to whoever owns the account, who may not be the person waiting for the lead. Zapier also holds runs for other reasons. Flood protection holds a burst of new items from a polling trigger when it passes a threshold, 100 by default, which is easy to hit on the first run of a Zap pointed at a large sheet. Check the held runs in Zap history as a routine, not after a customer asks.

Is a bigger plan the answer? Only after the audit below. If the tasks are real work, such as one invoice per sale or one message per ticket, the plan is the right size for the business and the fix is to pick the right tier on Zapier's pricing page. If half of them are lookups before a filter, an upgrade pays for the waste every month from then on.

Start from usage, not from suspicion. A bill is rarely spread evenly across an account, so rank before you read. This ranking is the first thing a Zapier consultant should do before proposing any rebuild, us included.

1. 01Open the Task usage tab in Zap history and set the date range to the last full billing cycle. It lists Zaps sorted by tasks used, and can be filtered by Zap or owner. Note the runs and tasks for the top few.
2. 02Check the total against the billing page. Zapier says the billing page is the most accurate figure because it includes every product, MCP among them, and it counts in UTC while Zap history uses your timezone, so expect the two to differ slightly.
3. 03Divide tasks by runs. Many runs at one or two tasks each is a busy trigger paying for a step before its filter. Few runs at dozens or hundreds of tasks each is a loop, or a scheduled Zap working through a whole list.
4. 04Open a heavy run in the Zap runs tab. It shows which steps ran and which were stopped. The step to fix is usually an action before the filter, or the first action inside a loop.
5. 05Look for repeats. The same record in back-to-back runs points to a Zap updating its own trigger, two Zaps on the same trigger, or whole runs being replayed.
6. 06List AI by Zapier and Code steps separately, with each AI step's tier and number of tools. These are the steps that can cost several tasks per run.
7. 07Write down the count you expect: runs a month multiplied by the action steps that should run each time. Where the history disagrees, the disagreement is the bug.

Zapier guarantees only up to 60 days of run data in Zap history, so export it if you want a baseline to compare against after the changes.

1. A filter straight after the trigger

Put the cheapest test first, and on Zapier the cheapest test is free. A filter as step two means a run that does not matter costs nothing at all. Where it breaks: a filter can only test what the trigger provides, and a thin trigger may not carry the field you need. Look for a trigger that does carry it before adding a lookup. If the lookup is unavoidable, set it to stop the Zap when nothing is found, so a miss costs nothing. A wrong filter also drops work silently, so check the stopped runs in Zap history for the first week.

2. Trigger on the event, not on every change

Many apps offer narrower triggers than updated record: a deal entering a stage, a status changing to a value, a new row rather than any edit to a row. Use the narrowest one that covers the job. Instant triggers are worth having for speed, but on Zapier they do not save tasks, because polls are already free. Where it breaks: some apps only expose a broad trigger. Then fix 1 is the whole answer, and it is usually enough.

3. Do the free work in free steps

Formatter handles dates, text, numbers and line items without using a task, while a Code step uses at least one. Paths branch without using a task. Storage by Zapier can remember that a record was already processed, or hold the result of an AI step, without using a task. Where it breaks: Formatter cannot do everything code can, and a chain of eight Formatter steps is harder to read than ten lines of code. Free is a reason to prefer a step, not a reason to make the Zap unreadable to the person who owns it.

4. Loops that do only what each item needs

Put actions that need to run once before the Looping step, which is Zapier's own advice. Filter the list before it enters the loop, so only the items that changed get processed. Where the app has an action that accepts line items or several rows at once, use one step instead of a loop. Where the output is a notification, collect the items with Digest and send one message. Where it breaks: a single bulk write hides which row failed, and a digest delays the message until it is released. If one bad row must not stop the rest, keep the per-item write and accept the tasks.

5. Replay the step, and make writes safe to repeat

When a run fails part-way, replay the failed step rather than the whole run, so the steps that succeeded are not billed and repeated. Make the writes safe to run twice, with find-or-create on a stable key rather than create, so a replay or a second trigger leaves the same result. Break a self-triggering loop with a filter on a field the Zap sets, and write only when the value actually changes. Keep error-handling paths short: one alert to a channel a team watches is enough. Where it breaks: find-or-create is a search plus a write, so it costs a task more than a blind create. That is cheaper than a duplicate invoice, but it is not free.

6. AI steps on the right tier

Apply the list in the June 2026 section: the lowest tier that passes your own test set, ordinary search steps instead of AI tool calls where they do the same job, and no repeat runs on input that has not changed. Where it breaks: an AI step trimmed until it is cheap and wrong costs more downstream than it saves, so keep a person on the decisions that matter.

7. Switch off what nobody owns

Sort the Zap list by owner and last run. Zaps owned by people who have left, old versions left on beside their replacements, and test Zaps still pointed at live data are the cheapest saving in any account, because switching them off costs nothing. Move the ones that matter into a shared account, so their notices reach someone. Where it breaks: a Zap that looks dead may run once a quarter. Switch it off before you delete it, and wait a full cycle.

When the structure is already tight and the bill still dominates, because the work itself is high-volume, many-stepped and per-item. That is the case our Zapier page names as the one where per-task billing outweighs everything else. Move that Zap, not the account. Simple, linear Zaps owned by the people who need them are what Zapier does best, and our Zapier alternatives article explains why most of them should stay.

• Keep Zapier as the connector. Where an app only integrates with Zapier, let the Zap catch the trigger and send the payload to a webhook in one step. The logic then runs somewhere that does not meter each step, and the Zap costs one or two tasks per record.
• Make, for loops. Make's aggregator collapses a list back into one bundle, so the steps after it run once rather than once per item. But Make bills a trigger's check as a credit, so a polling Zap ported unchanged can cost more there. Our Zapier to Make migration guide works through that arithmetic.
• n8n, for volume. n8n Cloud meters each workflow execution rather than each step, and self-hosted n8n does not meter at all, which moves the cost into servers, upgrades and someone on call.
• A small service in code, for the one loop that carries the bill and needs a run history and retries. FlowForge, a workflow runner we built with schedules, webhook triggers and per-flow run history, is the kind of thing we reach for. It is not a Zapier build.

Where it breaks: a move is a rebuild, because Zaps have no export another platform can run. Do the sum over a year: tasks saved against the cost of the rebuild and of running the replacement. If the saving does not clearly win, restructure and stay on Zapier.

A disclosure. Skofi is paid for Zapier audits, rebuilds and migrations to Make, n8n and code, so we gain from either answer in this section. Our Zapier evidence is 40 Zapier jobs on Upwork since 2024, a selection of which is listed on our Zapier platform page, rather than a long-form case study, and every task count in this article is an illustration with its inputs stated, not a client result. Check the arithmetic against your own Zap history.