What 8 Zapier accounts look like from the inside: findings from our audits

That a Zapier account is mostly history. Across eight accounts, about a quarter of the Zaps were switched on, fewer still had run in the previous month, and within the ones that ran, a single Zap usually accounted for most of the tasks and a single Zap for most of the errors. The table gives the headline figures, each with the period it covers.

Where this breaks: eight accounts is a small sample, chosen by the fact that we were hired into them. The percentages describe these accounts and nothing wider. What carries over is the method, which is set out near the end.

The audits were carried out and supplied on 21 October 2026 and were read-only: no Zap, run, connection or setting was changed, and no credentials, webhook addresses or personal data from runs were copied. For each account they record the plan, every Zap with its trigger, steps and on or off state, the task counters Zapier shows, and Zap history for roughly the previous 30 days.

Three rules govern the numbers. First, tasks are reported per account for that account's own billing period and are never added together, because each account's period starts on a different day. Second, runs and errors come from Zap history for 22 September to 21 October 2026 in every account that had any (to 20 October in the membership account), so those are added. Third, the agency workspace is one account: its plan, its task total and its 254 runs are counted once, not once for each of the five businesses in it.

The three Free-plan accounts had not run a Zap in 60 days and earlier history was not available, so they contribute to the counts of Zaps and plans and to the design findings, and nothing to tasks, runs or errors. The case studies describe 78 Zap entries, where a group of near-identical Zaps is one entry. Counts of error handling and drafts below are per entry.

45 of the 171 Zaps were switched on. Only one account, the six-Zap membership business, had everything on. In the five paid accounts 43 of 111 Zaps were on, and in the three Free-plan accounts 2 of 60. Being switched on is not the same as doing anything, either: every one of the 4,143 runs in the month before the audit came from 26 Zaps, so 19 Zaps were on and had not run in that window. Some of those are meant to be quiet, such as a Zap that fires once per course cohort, and one was new the day before the audit.

The rest of each list is what building leaves behind. In the private lender's account 3 of 18 Zaps were on and 7 of the 15 off ones had never been published or were incomplete: earlier attempts at the same document flow. In the medical-device team's account 4 of 33 were on, and about 20 of the others were dated copies of one webinar Zap. Unpublished drafts sit beside the live version in 26 of the 78 Zap entries, across seven of the eight accounts, and 11 of those entries are switched on, which means someone opening the Zap can read logic that is not the logic running.

The Free-plan accounts are the sharper case. In all three a Pro trial had expired and Zapier had disabled the multi-step Zaps. The telehealth provider's 13 Zaps and the furniture maker's 18 were all off. The nutrition coaching business had 2 of 29 on, both two-step Slack notices, while the Zaps that enrol a buyer in the coaching app were off. An off Zap is harmless. An off Zap that somebody believes is on is a customer who paid and got nothing. The audit cannot say whether that happened here.

Where this breaks: off does not prove the work stopped. The furniture maker later had a Make scenario building its Xero quotes straight from the web order, so its Zapier account is a retired system, not a broken one. The audit cannot tell the two apart from inside Zapier, and neither can a new member of staff. That is the argument for deleting or archiving what is retired.

Zapier counts a task for each action step that runs successfully, so the bill follows a Zap's volume multiplied by its paid steps. In four of the five paid accounts, one Zap used more than half of the tasks in the last full billing period.

Both accounts that went over were on 750-task plans, and in both the overage traces to one place. At the lender, two chained Zaps that file signed DocuSign PDFs on monday.com records used 1,169 of the 1,180 tasks. In the agency workspace, one client's Zap, which mirrors app subscription changes into a sheet and Mailchimp, used 1,222 of 1,289. In the following period, 22 September to 21 October, it had used 842 of the 886 tasks counted, and by the audit day the workspace had used up its 750 plan tasks and a further 100 pay-per-task tasks (the counter and the allowance figures are as Zapier showed them and do not reconcile exactly). Four other businesses share that allowance. The agency's own Zap meant to warn at 80% of the allowance was switched off and built on deprecated apps, so nothing warned anyone.

Run counts are a poor guide to cost. The lender's third live Zap ran 682 times in the Zap-history window, more than any other Zap in that account, and its filter stopped 672 of those runs. It used 11 tasks in the last full period. The filter is free, so those runs cost nothing, which is the point our article on Zapier tasks makes at length (/insights/zapier-tasks-cost).

Where this breaks: the coaching account. Its biggest Zap used 28% of the tasks, seven Zaps used between 35 and 288 each, and the total sat at 69% of the allowance. There is no single Zap to fix there and no need to. And a plan can be wrong in the other direction: the medical-device team used 3,791 tasks of 10,000.

Zap history for 22 September to 21 October held 4,143 runs across the five paid accounts and 119 of them errored, 2.9%. By account the rate ran from none in 170 runs (the membership community) to 6.2% (the lender: 69 of 1,110). An account-wide rate hides more than it shows, because the errors are not spread out. Of the 26 Zaps that ran, 10 had at least one errored run. One Zap produced 67 of the 119 and three produced 98.

• The lender's envelope-matching Zap errored on 67 of 270 runs, about a quarter, and halted safely on 52 more when no draw was found. The audit's reading is that most were envelopes with no matching loan number in the subject line, or completions that had nothing to do with draws.
• An industry association's directory-listing Zap, in the agency workspace, errored on all 4 of its runs. A fix was sitting in an unpublished draft.
• The coaching business's weekly Mailchimp sync errored 8 times in 100 runs, twice in each weekly batch, which points at the same two contacts every week.
• The medical-device team's two busy Zaps errored 15 times in 1,020 runs and 16 times in 677. Low rates, and each one a lead or a training record that did not reach Marketo unless someone replayed it.

What was in place to catch them: not much. Of the 78 Zap entries, 55 record no error handling at all, 19 rely on filters and guards that stop a bad run early, 2 use some other deliberate strategy, and 2 use Zapier's error-handling path. Autoreplay, which retries a failed step automatically, was on in one paid account and off in four, and all 119 errored runs were in those four. That does not show autoreplay would have saved them. The one account with it on is six simple Zaps and 170 runs, which is too little to credit the setting. It does mean each of the 119 stayed failed until a person replayed it.

An error path is not a fix either. The subscription-sync Zap has one, and 42 of its 240 runs ended there, on top of 3 that failed outright. Those 42 are not in the 119. A path that catches the same failure 42 times in a month is a report nobody has read. Our article on why automations fail in production covers the silent version of this in general terms (/insights/why-automations-break).

In six of the twelve builds, the list of what we would change includes the key used to find a record. The coaching business's daily syncs find an engagement in monday.com by its name. The lender's Zap takes the first number in a DocuSign subject line as the loan ID. The industry association's Zap finds a member's company in HubSpot by email domain. The subscription app's Zap decides monthly or yearly by whether the product name contains the word. The telehealth provider's Zap matched a lead by name before email. The furniture maker's Zap for manual orders gathered an order's lines by the customer's email address, which pulls in a repeat customer's earlier orders.

Each of these worked on the day it was built, and each fails in the same way: somebody renames something, writes from a personal address, or orders twice. The failure is loud in one account and silent in another. At the lender it shows up as the 67 errored runs above. At the coaching business, rows that find no match are filtered out, not errored, so a renamed engagement stops updating and Zap history shows a clean run. In that account 118 runs in the window halted because no matching record was found, 70 in one Zap and 48 in another, and nothing in the history says how many of those should have matched.

The fix is dull and reliable: carry an ID. Write the other system's record ID onto the record when it is created and match on that afterwards, which is what the same coaching account's status mirror already does with the engagement ID. Where this breaks: when the trigger does not carry the ID and the source app gives you no field to put one in. Then the honest options are a lookup table you maintain or an alert on every miss. Our article on Zaps running twice covers the write side of the same problem (/insights/zapier-zap-running-twice).

Four of the twelve builds, in three of the eight accounts, repeat one Zap per thing. The medical-device team's account has about 20 dated copies of a webinar-booking Zap among its 33, one for each run of session dates. A clinician-education business has eight per-cohort enrolment Zaps among its 14, five now off. The industry association has one seat-provisioning Zap per course. The coaching business has one status-mirror Zap per status.

This is where much of finding 1 comes from. Each copy was correct, each new course or date added another, and nobody deleted the old ones. The alternative is one Zap and a lookup table, so that a new run of dates is a row in a table and not a new Zap. Where this breaks: sometimes the trigger forces the copy. The coaching platform's trigger filters on a single status, and the webinar copies exist because a new Meta lead form was launched for each run of dates. In those cases the copies stay and the discipline is switching off and archiving the old ones.

On what the accounts are made of: Filter appears in seven of the eight, and Webhooks or Code by Zapier in five. monday.com appears in three accounts and in 31 of the 78 Zap entries, Google Sheets and Mailchimp in three accounts each. That mix reflects who hires us and should not be read as a ranking of apps.

The same audit, in the order that finds the most for the least effort. Nothing here changes a Zap.

1. 01Check the plan first. If the account has dropped to Free, look at which Zaps Zapier has disabled and whether anybody is doing that work by hand. In the three accounts where we saw this, every multi-step Zap was off.
2. 02Count the Zaps that are on, then count the ones with a run in the last 30 days of Zap history. For each Zap that is on and idle, decide whether it is waiting for a rare event or forgotten.
3. 03Open the Task usage tab in Zap history and rank Zaps by tasks for the last full billing period. Work out the top Zap's share. If it is over half, that Zap is your bill, and the plan should be sized to it.
4. 04Compare that period's total with the plan's allowance, and find out whether pay-per-task billing is on. If you have a usage alert, confirm it is switched on and still works.
5. 05Filter Zap history to errored runs for the last 30 days and group them by Zap. Expect one or two Zaps to hold most of them. Open three runs of the worst one and read the failing step.
6. 06Look at the autoreplay setting, and at which Zaps have any error handling. Add an alert to the steps where a failure means somebody paid and did not get what they paid for.
7. 07For every Zap that searches for a record, write down what it searches by. Replace names, email addresses, domains and text matches with an ID wherever the systems can carry one.
8. 08List Zaps that differ only by course, date, status or product. Merge them behind a lookup table where the trigger allows, and switch off and archive the ones for dates that have passed.
9. 09Publish or discard every draft that sits beside a live version, and rename any Zap whose name no longer says what it does.
10. 10Look for API keys typed into Webhooks steps, which two of the twelve builds had, and move them out of fields that everyone with access to the Zap can read.

If you would rather see what the result looks like before doing it, the twelve case studies at /work/zapier are this audit written up account by account, and our Zapier page (/platforms/zapier) says how we work in a client's account. Whether any of this is a reason to leave Zapier is a separate question, and usually the answer is to move one Zap, not the account. Our Zapier alternatives article argues that in full (/insights/zapier-alternatives).

• Anything about Zapier users in general. Eight accounts, all ones we were hired into. Where the audit gives a country it is Australia or the United States, and several of the businesses are in coaching or education.
• Trends. Everything was read on one day. The task figures cover one billing period per account and the run figures one month.
• Money. The audits record tasks, not invoices, so there is no cost figure here and we have not estimated one.
• Why three accounts dropped to the Free plan, or what the businesses did instead. The audit shows the state, not the decision.
• What happened to runs after the two allowances were used up. The audits do not record whether any were held.
• Whether a halted or filtered run should have gone through. History records that a search found nothing, not whether something was there to find.