Zap running twice? Seven causes of Zapier duplicates, and the fixes

Because something gave the Zap two triggers for what you think of as one event, or because the Zap wrote twice from one trigger. Zapier's own troubleshooting pages list the usual suspects: broad trigger settings, more than one Zap using the same trigger, unintentional loops, static values in an action, and replays after a timeout. Add webhook senders that retry or send arrays, and polling triggers whose IDs change, and you have the seven causes below. Each leaves a different trace in Zap history, so the table pairs every cause with what to look for and the fix.

The order matters less than it looks. Whatever the cause, the second run is only a problem because the write is unconditional. A Zap whose action searches for the record first, or checks a lock, can be triggered twice and still leave one record. That is why the fixes section starts with the write.

Start from one duplicated record and work backwards. A client in Brisbane hired us in mid-2025 with exactly this brief, to find the root cause of duplicate Zaps firing and fix the setup, and this is the order of checks we use on jobs like that. It takes minutes per record and saves rebuilding a Zap that was never the problem.

1. 01Copy a value that identifies the duplicated record: the source record's ID, an order number or an email. Search Zap history for it. Zapier recommends this search to tell whether the problem is one Zap or several.
2. 02Count the runs and note which Zaps they came from. Runs from two Zaps is cause three, and you can stop there.
3. 03Open each run and compare the trigger's data. Same ID and same payload means the same thing arrived twice: look at webhooks, replays and the source app. Same ID with a different modified time or field values means an updated trigger. Different IDs for what is really one record means the ID changed, or the source created two records.
4. 04Read the step statuses on the earliest run. An errored or timed-out write followed by another attempt is cause four. A timed-out step may still have created the record, because a timeout only means the app was slow to answer.
5. 05Check the timing. Runs a few seconds apart, each carrying a different line item from one request, are array forking. Runs minutes apart, each following the Zap's own write, are a loop.
6. 06Then look outside Zapier: the sender's webhook delivery log, and the target app's record history where it keeps one, which can show when each copy was created and by which user or connection.

Most app triggers on Zapier poll. Zapier asks the app for recent records on an interval and runs the Zap for each record it has not seen before. Seen means the record's unique ID, by default the field called id, compared with the IDs that Zap has stored. When a Zap is turned on, Zapier's developer documentation says it takes an initial poll and stores those IDs as already seen, and the list is cleared when the Zap is turned off.

So a polling Zap runs again for a record when that record comes back with an ID the Zap has not stored. Zapier's developer docs warn that changing or removing an integration's primary key, or changing the endpoint behind a trigger, can make old records trigger a Zap. Zapier's help centre adds another route: a large deletion in the trigger app can surface older items the Zap then picks up. Neither is something you would see in the Zap itself, which is why the symptom often arrives straight after an app or integration update.

New or updated is not new

Zapier's trigger guide separates New triggers, which fire for new items, from New or Updated triggers, which also fire when an existing item changes. For updated-item triggers, Zapier's developer guidance is to combine the record's id with its updated time so that each update counts as a new item. How a particular app builds that key is up to its integration, so treat every edit as a possible run. A Zap that creates something on an updated trigger will create again on each edit that gets through.

If creation is the job, use the New trigger. If the Zap needs the update trigger, because it is waiting for a status to change, put a filter straight after the trigger on that change, such as status equals Won, and record that the Zap has handled the record. Filter steps use no tasks, so the filter costs nothing to add. Our Zapier page makes the same point about cost: Zaps triggering on every update when they only care about one field are among the first things an audit finds.

Yes, and Zapier will not stop them. Its deduplication only checks within the same Zap, so every Zap using a trigger runs for every record. The usual sources are a copy made for testing and left on, an old Zap and its rebuild both switched on, and a colleague's personal version of the same automation. Search the Zap list by trigger app and look for two Zaps that create the same thing.

The fix is one owner Zap per trigger and per job. Merge the duplicates into one, switch the others off, wait a full cycle in case one of them ran something nobody remembered, and then delete them. Move the survivor into a shared account, so its error notices reach a team rather than one person's inbox. Our Zapier page gives the same advice for Zaps that turn themselves off.

Paths can duplicate inside a single Zap. Zapier runs every branch whose rules match, and more than one branch can be set to always run, so two branches that both create a record will both create it. Make the conditions mutually exclusive, or use the fallback branch, which runs only when no other branch in its group does.

They can. Replaying a whole Zap run repeats the steps that already succeeded, so a create step that worked the first time creates again. Zapier's duplicate-data page is specific about timeouts: if a run shows a timed-out error, replaying the errored action may be creating duplicate data. The app took too long to answer, which does not mean it did nothing.

Autoreplay does the same thing without anyone pressing a button. Where it is switched on, Zapier retries a failed step up to five times, with the last attempt about ten and a half hours after the first error, and it does not send the error email until the last attempt fails. A target app that times out after writing can therefore collect several copies before anyone hears about it. Autoreplay does not replay held runs, which have to be replayed by hand.

One detail catches people who already use find-or-create. Zapier says search steps are not re-run when a run is replayed; the replay uses the search's original output. A find step that found nothing on the first attempt will not see the record that attempt went on to create. Before replaying a timed-out write, check the target app yourself. If the record is there, mark the run as handled rather than replaying it.

Zapier states that instant triggers do not use deduplication, because the apps are expected to send only new data. Whatever a sender delivers twice therefore runs twice. Many webhook senders retry a delivery they believe failed, so a slow or dropped acknowledgement can produce a second, identical delivery. The sender's delivery log, where it has one, shows this directly: two deliveries of the same event.

The other webhook pattern looks like duplication and is not. When the Webhooks by Zapier trigger receives an array, it treats each object in the array as a separate item and starts a separate run for each one. Zapier calls this forking. If you wanted one run, nest the array under a key so the trigger reads a single top-level object, which only works if the sender lets you shape the payload, or ask the sending API for one object at a time where it has a limit parameter.

The source app really did send two events

Sometimes Zapier is doing exactly what it was told. A person submits a form twice. An app sends one event when a record is created and another when it is completed or paid. A CRM fires an update for each field a sync touches. Zap history shows two different trigger records here, and the fix is a decision rather than a setting: which event is the Zap for? Filter on that event, or on the status that marks it, and let the others stop at the filter. Where two submissions are genuinely the same request, guard the write with a lock key on whatever identifies the request.

Because it writes back into the app it watches. The Zap updates a record, the update fires the trigger, the Zap runs again, and if that run writes too the loop continues until something stops it. Each pass is billed for its actions, which is how a loop shows up in task usage before anyone notices the data.

Zapier's help centre gives two fixes. Put a unique marker, such as a short tag, into a free-text field the action writes, and add a filter before the action that continues only if that field does not contain the marker. Or add a field such as Processed by Zap in the app, write to it in the update step, and filter so the Zap continues only when that field is empty. For two Zaps keeping two apps in sync, each writing into the other's trigger, Zapier's advice is to swap Create actions for Find or Create, so the return trip finds the record instead of making another.

Make the write safe to repeat, then reduce the second triggers. The five fixes below are in the order we apply them. The first two make a second run harmless whatever caused it. The last three remove the causes you can control.

1. Find-or-create on a stable key

Replace Create with a search that creates the record only when nothing is found. Many search actions on Zapier offer this as an option in the step, phrased as create the item if it does not exist yet. Where the app has no such option, Zapier's pattern is a search step set to continue when nothing is found, then Paths: one branch updates when the Zap Data was found field is true, another creates when it is false. Search on a key that identifies the record uniquely and never changes: an order number, an external ID, an email. Names are not keys.

A weekly update we took on for a client in New Hampshire shows why the key matters. The brief was to take rows from a spreadsheet each week, match them to records in a SaaS platform by first name, last name and location, and update the records that matched. That is the right shape, because it updates rather than creates, and the weak point of any name-based match is two people with the same name in the same place. A match like that needs a rule for ties, not an assumption that there are none.

Where it breaks: find-or-create is a search plus a write, so it costs a task more than a blind create, as our Zapier tasks article notes. In some apps a record created a moment ago is not yet returned by search, so two runs a second apart can both find nothing and both create. And on a replay the search output is reused, as above. For those cases, add a lock.

2. A lock key in Storage by Zapier

Storage by Zapier keeps small key-value pairs between runs, and its steps use no tasks. To lock, put an Increment Value step before the write, keyed on the source record's ID, and a filter that continues only if the returned value is 1. The first run gets 1 and writes. A second run for the same record gets 2 and stops. Set Value If, which sets a value only when the current value matches the one you give, can do the same job. Zapier's StoreClient documentation describes increment and conditional set as atomic, which is what makes this safe when two runs arrive together. Test it anyway with two runs fired at once, and test what the step returns for a key that does not exist yet.

Where it breaks: Zapier's Storage page currently allows keys of up to 32 characters and 500 keys per store, and removes keys after a period of inactivity, which one Zapier page puts at two months and another at three. That makes Storage a short memory for retries and double-fires, not a permanent ledger. For a permanent record of what has been processed, write a flag or the source ID into the target app itself and search on that.

3. A filter on a field

A filter straight after the trigger, on the field that marks the event you want, stops updated triggers, second events and loops before any paid step runs. Filter on a status value, on a Processed by Zap field being empty, or on a field the Zap itself sets. Where it breaks: a filter can only test data the trigger provides, so if the trigger does not carry the field, a search has to come first, and that search is billed on every run.

4. One owner Zap per trigger

One Zap per trigger and job, in a shared account, named so the Zap list says what it does. Where several Zaps must touch the same records, Delay After Queue with the same queue title in each Zap makes their runs wait their turn, which removes most same-second races. Zapier is clear that it cannot guarantee runs will never overlap, because replays and infrastructure slowdowns can still collide, so a queue complements a lock rather than replacing one.

5. Writes that are safe to repeat

Prefer update to create wherever the record should already exist. Where the target app or API supports an upsert on an external ID, or an idempotency key, use it from a webhook or API request step, so the target app does the deduplication. On our fleet order automation, which is not a Zapier build, inbound orders are matched against existing rows, so a resent order corrects its row instead of adding a second.

The same instinct runs through a Zapier build we did for a sales team on Close. The brief was an automation that assigns new Calendly call bookings in Close to the team member they booked with and attaches phone numbers to the correct lead: the job is to find and attach to the existing lead, not to make a new one. The client's review: "Saveez was amazing. He went above and beyond and even made suggestions to help the optimization of my current tech stack. Highly recommended" — Upwork review, Zapier + Close + Calendly build.

Because the Zap's steps are bound to a version of the app's Zapier integration, and versions change. Zapier says it updates Zaps to the latest version automatically when necessary, but breaking changes can stop it doing so, and then the step keeps running on an old or deprecated version until it fails. Fields can disappear between versions, new ones appear, and anything mapped downstream from a field that no longer exists breaks with it. A client in Manchester hired us in March 2025 with exactly this brief: six Zaps had broken after one of their apps was updated, and they needed them working again.

1. 01List every Zap that touches the updated app, with its last error. Group them by cause: a connection that needs reconnecting, a field that no longer exists, a trigger that changed.
2. 02Move each affected step to the current app version. Zapier's route is the step's Setup tab: change the app in the App field, choose the version without a version number or a Legacy or Deprecated tag, then test the step. Zapier notes that once you publish the updated Zap you cannot simply switch back, so copy the Zap first if you want a way back.
3. 03Remap the fields in every downstream step, not only the step you changed. The step that errors is often two steps after the one that changed.
4. 04If the trigger's version changed, watch for old records firing again, since a changed key is one of the routes Zapier names for that. Test with one real record before switching the Zap on.
5. 05Only then replay what failed while the Zaps were broken, the failed steps rather than whole runs, after checking the target app for anything that was half written.

Field mapping is where most of this work goes. A one-day job for a business in Oregon was exactly that: fixing the field mapping for an AI receptionist that sent customer messages into HubSpot through a form via Zapier. The client's review: "Saveez was incredibly kind and helpful. He fulfilled our needs quickly and excelled in his work. I highly recommend him!" — Upwork review, Zapier + HubSpot form fix, Oregon, USA.

Skofi has done 40 Zapier jobs on Upwork since December 2024, alongside Make, monday.com and Airtable work, and as of 21 October 2026 the profile is Top Rated with a 100% Job Success Score across 114 jobs. The duplicate-Zap job in Brisbane and the six broken Zaps in Manchester are two of those. Upwork records the client's brief and their review, not what was found or delivered, so we describe them as briefs and do not present them as case studies. We have no published Zapier case study, as our Zapier tasks article also says.

Skofi is paid to troubleshoot, rebuild and migrate Zaps, so weigh our advice with that in mind. Most of the fixes in this article are things a Zap's owner can make in an afternoon, for free, with steps that use no tasks. If the duplicates come from the shape of the work, a process that branches, iterates and has to reconcile records across systems, our Zapier page explains when that work belongs on another platform. For simple, linear Zaps, it usually does not.