Your Zap ran all night: how to stop a Zapier loop eating your tasks

The email arrives before the evidence does

The task-limit warning email lands at three in the morning, and the one saying you're out follows minutes later. By the time anyone reads either, the month is gone. The Zap that spent it is still on, still running, still reporting success on every single run.

Nothing errored. That is the part people refuse to believe until they open Zap History and find a wall of green where they expected red. A Zapier infinite loop doesn't look like a failure in the interface. It looks like the most productive Zap anyone in the company has ever built.

Someone hit the same wall on Make and described it better than any documentation has:

"just 100 transactions in infinite loop consumed 20,000 credits and each transaction only cost 2 credits" ... "no errors, infact i can see ton of successful transactions in the log."

— a user, Make Community, December 2025

Why didn't Zapier stop it?

Because the only automatic brake watches errors, and a loop makes none. Zapier pauses a Zap "if it hits an error 95% or more percent of the times that it has run in the last 7 days", per its error settings documentation. Thousands of successful runs never come close to tripping that wire. The limits that do exist are about bursts rather than patterns: flood protection holds a Zap when 100 or more events arrive at once, and per-plan rate limits cap requests per window (docs). A steady cycle running inside those limits trips nothing at all.

Three more details keep the loop out of sight until the bill:

1. Triggers are free. Zapier's task usage documentation counts successful action steps and explicitly excludes all trigger steps. Half of what the loop does is invisible on the usage screen, and it's the half doing the re-arming.
2. Deduplication is per-Zap. Zapier compares each record's unique ID against IDs that Zap has seen before, but "the deduplication system only checks within the same Zap" (docs). Two Zaps pointed at each other never share that memory.
3. Instant triggers have no dedupe at all. Same page: "Instant triggers do not use deduplication because apps only send new data." A webhook-driven loop has no floor and no polling interval to slow it down.

What does a loop actually look like?

Two shapes, and both are things people build on purpose. The first is a mirror between two apps: Zap A copies changes from App 1 into App 2, Zap B copies them back. Each write registers as a change on the other side, so each write re-arms the opposite trigger. The second needs no partner at all.

Zapier documents the second one in its own trigger guide:

"If your Zap writes data back to the same app and resource that your trigger monitors, the update can retrigger the Zap, creating an infinite loop that rapidly consumes tasks."

— How Zap triggers work, Zapier Help

The cleanest published example is two steps long. A user built a Zap on the "New or Updated Event" trigger in Google Calendar with one action, "Add Attendee/s to Event", and reported it burning over a thousand tasks a day: "I have certainly not added thousands of new events to the calendar" (Zapier Community). Adding the attendee updated the event. The updated event fired the trigger. A Zapier staff reply on that thread, relaying the support team's diagnosis, names the mechanism exactly: "every time your Zap added an attendee to an event this caused the same Zap to trigger due to the event being updated."

Two-way sync is the mirror version of the same trap, and Zapier's position on it is worth reading twice: "Zapier does not support two-way syncing between apps right now." The suggested workaround is two opposite Zaps, with a warning attached to it: "Be careful not to create a Zap Loop" (docs). The setup people reach for first is officially a workaround, and it ships with a caution label attached.

Stop the bleeding: the first ten minutes

Turn things off before understanding anything. Diagnosis while the loop runs costs tasks for every minute it takes, and on a "new or updated" trigger even your cleanup is another update. The order below stops the spend first and asks questions second.

1. Turn off both Zaps, not one. Zapier's own instruction: "Turn off the Zap that is looping right away. If two Zap workflows are looping together, turn off both" (docs). One live side is enough to restart the cycle the next time a record changes.
2. Switch off pay-per-task if it's on. Billing settings, one toggle, and "pay-per-task will stop being used immediately" (docs). This turns an open-ended invoice back into a hold.
3. Open Zap History and switch to the Task usage tab. It lists your Zaps sorted by tasks used, highest first. The offender is the top row with a number that has nothing to do with its job.
4. Read the signature. Many runs, all Successful, evenly spaced at your polling interval, and the same record ID or email address recurring in the trigger data. Open two runs hours apart. If it's the same record both times, you're looking at a loop.
5. Decide about the queue deliberately. Runs sitting as On hold, Delayed, Scheduled or Running have not spent their tasks yet. Replaying them bills again and re-arms the loop. If autoreplay is on, turn it off before it retries on your behalf.
6. Check what the loop wrote. Duplicate contacts, overwritten fields, and worst of all messages that actually went out to customers. Emails and texts can't be recalled, and the "correct" value after a ping-pong is whichever side happened to write last.

This is the same shape of failure as an automation that stops firing entirely: the dashboard reports health while the business quietly pays for it. Silence and noise are the same bug seen from opposite ends, and both are what a Zapier fix covers.

Can you get those tasks back?

No. Tasks already spent are spent, and deleting the run history doesn't return them. The confusion is understandable, because Zapier's delete button means two completely different things depending on the status of the run you're deleting, and one of those meanings is genuinely useful right now. Zapier's own warning pop-up on the delete button says as much: deleting runs does not return the tasks they used, and that usage still counts towards the monthly allotment.

One thing worth checking on your own account before you assume you're capped: pay-per-task keeps Zaps running past the plan limit and stops only at three times your allowance. The rate is quoted differently in three places. Zapier's plans announcement advertises "one easy rate of 1.25x the cost of a task on your plan" (docs), the pay-per-task article now says it depends on your plan and billing cycle, and the pricing page lists 2.5x for monthly plans against 1.25x for annual. Read your own billing screen rather than trusting any of the three. With pay-per-task on, the loop bills its way past the plan limit before anything stops it.

What makes a runaway Zap worse?

Four moves, all of them reasonable instincts. Upgrading the plan buys the loop more room. Replaying the held backlog pays for the same accident twice. Adding a Delay slows the spend without breaking the cycle. Cleaning up duplicate records while the Zaps are still on feeds the trigger that caused them. Each one costs money or wastes the outage you're already having.

• Upgrading the plan first. The bigger bucket fills with the same water, and the queue of held runs is waiting to drain into it. One business upgraded the moment it hit the limit and still came back to dozens of Zaps held over the weekend.
• Replaying the held backlog to catch up. Replays are billed again: "any successful steps will count towards your task usage, even if they were already counted in a previous run" (docs). A backlog of loop artefacts replayed is the same accident, paid for twice.
• Adding a Delay and calling it fixed. Delay and Digest only change how fast a loop spends money. A cycle slowed to hourly is still a cycle.
• Cleaning up the duplicate records while the Zaps are still on. On an updated-record trigger, your cleanup is more updates, which is more fuel. Off first, then tidy.

The fixes that hold, and what each one costs you

There is no universal fix, which is why the vendor documentation reads like a menu. The two that hold in most small setups are a marker field with a Filter on both Zaps, and one-way sync with a nightly reconciliation. Every pattern in the table works, and every one charges you something: schema, flexibility, tasks, or the freedom to edit records in both systems.

The comparison that puts this in perspective is what other platforms do with the same problem. Microsoft warns you as you save the flow, before it has ever run:

"Actions in this flow may result in an infinite trigger loop. Please ensure you add appropriate conditional checks to prevent this flow from triggering itself."

— Power Automate anti-patterns guidance, Microsoft Learn

Notion forbids the shape outright: "Database automations can't be triggered by other automations" (docs). HubSpot skips the action and writes the reason in the log: "The enrolled deal was created by this workflow, so this action was skipped to prevent an infinite loop" (docs). Make ships both a "Cycles per run" cap and an "errors before deactivation" counter (docs) — and the December 2025 user above had set both, to one cycle and three errors, and still burned twenty thousand credits. Neither guard could fire: the cycle cap limits cycles inside a single run, not the number of runs, and the error counter is "ignored" outright when a scenario starts with an instant trigger. Zapier gives you Filters, which run after the trigger has already fired, and a documentation page. The guard is your job.

When it's cheaper to hand it over

One Zap writing to the record that triggers it is an evening's work: change the trigger, add the filter, watch the history for an hour. Two apps mirroring each other, with weeks of duplicated records behind them and no field recording who wrote what, is a different job. The loop is the easy half. Deciding which side owns which field, and which of the two values is the real one, is the half that takes the time.

Users who have built these loops say the same thing about templates, in so many words: there is no recipe, every app pair needs its own solution.

That's our line too. A runaway Zap and the cleanup behind it is a single scoped job with a fixed price, and you can size it yourself before talking to anyone. If the loop is in Make rather than Zapier the mechanics are identical and the bill grows faster, because a Make module's operation count "depends on the number of bundles it processes" (docs), and since August 2025 those operations bill as credits at one to one. What a scoped repair covers end to end is written out in this worked example.

Sources

• How is task usage measured in Zapier? - what counts as a task, and why triggers are free
• How Zap triggers work - polling intervals, deduplication, the documented self-loop
• Zap is stuck in a loop - Zapier's own remedy and prevention patterns
• Does Zapier support two-way syncing? - the official position and its caution
• Decide how your Zap handles errors with advanced settings - the 95% error rule
• View and manage your Zap history - Task usage tab and what deletion does
• Replay Zap runs - replays are billed again
• How pay-per-task billing works - the 3x ceiling and the toggle
• Zap limits - flood protection and rate limits
• Review run statuses - what each status means before you delete anything
• Power Automate anti-patterns - design-time loop warning
• Database automations, Notion - automations cannot trigger automations
• Workflows FAQ, HubSpot - the loop the engine catches for you
• Scenario settings and operations, Make - cycle caps and how operations are counted