Zapier Zap Not Triggering? 10 Real Causes and How to Fix Each One

You open Zap history expecting an error and find nothing at all. No red banner, no failed step, no half finished run. An empty list, and a Zap that says it is on. A Zapier Zap not triggering is the least helpful failure in automation, because every other kind of breakage at least leaves evidence behind.

I build automation for course platforms, funnels and membership sites, and Zapier sits in the middle of most of them. Almost every time somebody hands me a Zap that will not fire, the Zap itself is fine. What is wrong is a rule about how triggers work that nobody ever told them: how often Zapier actually looks, what counts as new, and where a run goes when it is neither successful nor failed. Ten real causes, in the order I check them, with the exact screen to open for each one.

How Does a Zapier Trigger Actually Decide to Run?

There are two kinds of trigger, and they fail for completely different reasons. A polling trigger means Zapier periodically asks your app whether anything new has appeared. An instant trigger means the app pushes the data to Zapier the moment the event happens, using a webhook, and it shows a small lightning bolt icon next to the app name in the Zap editor.

Most triggers are polling triggers. That single fact explains a large share of the panic, because a polling trigger is silent by design between checks. Nothing appears in Zap history until the next poll runs, so an empty history at 30 seconds old means nothing at all.

The second mechanism is deduplication. Zapier does not ask your app for “everything since the last check”. It asks for a list, compares each item’s unique ID against IDs it has already seen, and runs only for IDs that are new to it. Zapier’s own documentation on how triggers work is direct about the consequence: a Zap will not trigger for old data, including anything that existed in your app before the Zap was turned on.

So a trigger has to clear four separate gates before you see a run: the Zap has to be on, the poll has to happen, the item’s ID has to be genuinely new, and the item has to match the trigger’s configured options. Ten causes, four gates, and the same symptom for all of them.

Cause 1: Is the Zap Waiting on a Polling Interval Rather Than Failing?

This is the most common false alarm by a wide margin. Somebody submits a test form, watches Zap history for two minutes, sees nothing, and concludes the automation is broken. On the Free plan they would need to wait 15 minutes before that conclusion means anything.

The polling interval is set by your plan, and Zapier publishes the numbers directly on its pricing page: 15 minutes on Free, 2 minutes on Professional, and 1 minute on Team and Enterprise. Paid plans can also adjust the interval for an individual Zap, although the dropdown only offers what the trigger app itself supports, since some apps set their own floor.

Cause 2: Did the Record Exist Before the Zap Was Turned On?

When you switch a Zap on, Zapier makes an initial call to the app, reads the existing items, and stores their IDs. Those IDs are now marked as seen. The Zap will never fire for them, no matter how long you wait or how many times you refresh.

This catches people twice. The first time is at setup, when they build the Zap around a row or a contact that already exists and then wonder why it stays quiet. The second time is subtler: turning a Zap off and back on rebuilds that list of seen IDs from scratch, so anything created while the Zap was paused gets absorbed into the new baseline and is skipped permanently.

Cause 3: Is the Run Held Rather Than Missing?

A held run is not a failed run and it is not an absent run. The Zap triggered, Zapier accepted the data, and then something stopped the run before the actions executed. In Zap history it carries the status On hold, which is easy to scroll past if you are scanning for red.

Zapier lists the reasons plainly, and they are mostly billing and connection problems rather than logic problems. One of the app accounts is disconnected. The account has reached its task limit for the billing cycle. The payment method on file expired. The Zap uses a premium app the current plan does not include. On Team and Enterprise accounts, an admin app access policy blocks the app entirely.

Two more are structural rather than financial. Flood protection kicks in when a single check finds enough new data to trigger more than 100 steps at once, which stops a runaway import from consuming a month of tasks in one poll. Separately, a Zap with more than 100 steps in it is held outright.

Cause 4: Did Zapier Turn the Zap Off After Repeated Errors?

Zapier protects you from a Zap that fails constantly by switching it off. The rule is specific rather than vague: according to Zapier’s documentation on paused Zaps, a Zap is automatically disabled when it errors 95% of the time it runs and has run more than 20 times in the past 7 days.

The warning you get depends on what you pay. Enterprise accounts get an email 72 hours before the shutdown, Team accounts get 24 hours, and Free accounts get no advance notice whatsoever. So on a Free plan the first sign is usually a colleague asking why the leads stopped, days after it happened.

This one is worth checking early because it hides in plain sight. The Zap toggle reads off, and everyone assumes a person turned it off.

Cause 5: Did a Filter Stop the Run Without Telling You?

If the run shows the Filtered status, the trigger worked perfectly. The conditions in a Filter step were not met, so no later step executed. People read this as “the Zap did not trigger” because the outcome looks the same from the destination app.

Zapier’s own list of reasons filters misbehave is worth reading in full, because almost none of them are the condition being wrong. A field arrives as “(missing value)” because the app sent nothing for it. The filter still references a field from an older trigger you replaced. The field existed in your sample data but is absent from real records. Two similarly named fields exist and the wrong one got mapped. AND was selected where OR was meant, so every condition has to be true instead of any one of them.

Two catch almost everyone. Invisible characters, meaning a trailing space or line break that makes an exact match fail against text that looks identical on screen. And format mismatches, where a date arrives as 12/31/2025 and the filter is comparing it against December 31, 2025.

One thing filters are not is case sensitive. Zapier states this explicitly across every text rule, including Contains, Exactly matches, Starts with and Ends with. If you have been chasing capitalisation, that is not your problem.

Cause 6: Has the App Connection Quietly Lost Its Authorisation?

Connections expire. A password change, a revoked OAuth grant, a removed user seat, a security policy that rotates tokens, an admin who cleaned up third party app access last month. Any of these breaks the connection without breaking anything visible in the Zap editor.

A connection issue between your app and Zapier is one of the five causes Zapier names in its official article on Zaps that are not triggering, alongside the Zap being off and the data being pre-existing. It is worth checking both directions, because Zapier can believe a connection is healthy while the app has quietly withdrawn permission on its side.

Cause 7: Is the Wrong Trigger Event Selected?

Most apps expose several trigger events that sound interchangeable and are not. New Item fires once when a record is created. New or Updated Item fires again on every subsequent edit. If you picked New Item and your real workflow depends on somebody filling in a field afterwards, the Zap is behaving exactly as configured and doing nothing useful.

The other half of this lives in the Configure tab. Trigger options narrow what qualifies, and a single restrictive setting quietly excludes everything you care about: the wrong list, the wrong folder, the wrong pipeline stage, a label that no longer exists. Zapier flags overly restrictive trigger conditions as a named cause of Zaps missing runs.

There is one more version of this that feels like a bug and is not. Some apps only surface records through their API if those records were created through the API. A record typed in manually by a person is invisible to Zapier no matter what the trigger is set to.

Cause 8: Is Pagination Swallowing Records Between Polls?

This one produces the worst version of the problem, which is a Zap that works most of the time. Every polling trigger asks the app for a limited page of recent records rather than everything. If more records are created between two polls than that page holds, the surplus is never seen and never runs.

Zapier gives a concrete shape to this: with a trigger that retrieves 100 records per poll, creating 124 records between checks means more than 20 of them get skipped entirely. No error, no held run, no history entry. They simply never existed as far as the Zap is concerned.

In practice this shows up after a bulk import, a webinar registration spike, a campaign send, or a migration. Anything that produces a burst rather than a trickle.

Cause 9: Did Someone Restructure the Google Sheet While the Zap Was On?

Google Sheets deserves its own cause because it is the most used trigger app and the most fragile one. Sheets triggers track rows by position, and deduplication remembers where it got to. Change the shape of the sheet underneath that and the trigger loses its place.

Zapier’s Google Sheets troubleshooting article walks through the exact mechanism. Delete five rows from a sheet that reached row 100 and the remaining rows renumber, but Zapier is still waiting for new rows to appear from row 101, so the next five rows you fill in never trigger anything. Rows added into the middle of a sheet are not treated as new at all, because only rows added at the bottom count.

The same article lists sorting the worksheet, renaming or adding or rearranging columns, renaming the spreadsheet or the worksheet, and frozen, hidden or protected rows and columns as things that break triggering. Blank rows cause their own version, because Zapier reads a blank row as the end of the sheet. A row containing only a formula is not blank to Zapier even though it looks empty to you.

Cause 10: Does It Work in the Editor Test but Never on Live Data?

This is the one that makes people doubt themselves, because the evidence looks contradictory. The test in the Zap editor passes every time. The published Zap does nothing.

The reason is that testing and running are not always the same route. For many instant triggers, the live event arrives as a webhook the app pushes to Zapier, while the sample you see in the editor is pulled back separately through an API request. When those two paths return differently shaped data, a Zap built against the sample will not match what actually arrives, and a step that references a field present only in the sample fails or filters out.

Webhook triggers have their own version. The payload has to arrive as JSON, XML or form encoded data at the exact URL the Zap generated, and a POST needs Catch Hook or Catch Raw Hook rather than a different trigger. A URL copied from an older draft of the Zap points at nothing.

What Is the Fastest Way to Diagnose a Zapier Zap Not Triggering?

Order matters here, because the cheap checks eliminate most of the causes above in under five minutes. Work down the list and stop at the first thing that explains the behaviour.

1. Confirm the Zap is on. Then confirm nobody switched it off, and that Zapier did not switch it off for you after a run of errors.
2. Check Zap history with no status filter applied. This is the single highest value step. An entry under Filtered, On hold, Errored or Delayed means the trigger worked and the problem is downstream, which removes six of the ten causes immediately.
3. Check the clock against your plan’s polling interval. 15 minutes on Free, 2 on Professional, 1 on Team and Enterprise.
4. Confirm the record was created after the Zap was turned on. If the Zap was ever paused, confirm it was created after the most recent time it was turned back on.
5. Run the trigger manually in the editor. If a manual poll finds the record, triggering works and the issue is interval, dedup or pagination. If it finds nothing, the issue is connection, trigger event or trigger options.
6. Reconnect the app account from the trigger step’s Account tab, and verify Zapier still has access from inside the app itself.
7. Empty the Configure tab of optional trigger settings and test with nothing narrowing the results, then add them back one at a time.
8. Search Zap history for the record’s own data, an email address or an ID, to establish whether Zapier ever saw it. This separates “never arrived” from “arrived and stopped”.
9. Toggle the Zap off, wait a minute, toggle it on. Last rather than first, because it resets deduplication and will hide evidence you have not gathered yet.

Why Do All Ten of These Look Identical From the Zap Editor?

Because the Zap editor shows you configuration, and none of these ten causes are configuration problems. The editor cannot show you that a poll has not happened yet, that an ID is already in the deduplication table, that a page of records overflowed, or that a token was revoked in another company’s admin panel three weeks ago.

Zapier is also unusually quiet by design. It sits between two systems it does not control, and a trigger that returns an empty list is a completely normal response, indistinguishable from an app that has stopped reporting. There is nothing for Zapier to raise an error about, so it does not raise one.

This is why Zap history matters more than the editor. The editor tells you what the Zap intends to do. History tells you what happened, and the run status list is genuinely precise once you read it properly. Filtered means conditions were not met. Safely halted means a search step found no result and stopped on purpose. Skipped means a preceding step’s outcome ruled it out. Scheduled means it errored and autoreplay is going to try again. Each of those is a different diagnosis wearing the same costume.

The same blindness shows up everywhere automation touches a system it does not own. It is exactly why an ActiveCampaign automation that will not trigger is almost always an entry rule rather than a bug, and why a ClickFunnels order form that will not submit gives you no error to work with. The tool reports on itself honestly and has no view of the thing that actually broke.

How Do You Stop a Zap From Breaking Silently Again?

Silent failure is the real problem, not any individual cause. A Zap that breaks loudly costs an hour. A Zap that breaks quietly costs three weeks of leads before anybody notices.

Turn on error notifications for the account and make sure they reach somebody who reads them, not a shared inbox nobody opens. Enable autoreplay on plans that offer it so temporary API outages and server timeouts retry themselves rather than counting toward the 95% error ratio that switches a Zap off.

Build a heartbeat into anything you actually depend on. A scheduled Zap that checks whether the important one has run recently and messages you when it has not turns a silent failure into a notification. It costs a handful of tasks a month and it is the single highest return thing you can add.

Watch task usage before it hits the ceiling, since hitting the plan limit holds every action across the whole account rather than just the Zap that consumed them. Prefer instant triggers over polling triggers wherever the app offers both, because they are faster and immune to pagination. And keep a written note of which Zaps watch which sheets and lists, so the person who reorganises a spreadsheet next quarter knows they are touching production.

One last trap worth naming: never let a Zap write back to the same resource it watches. Zapier warns about this directly, because the update retriggers the Zap, which updates again, and an infinite loop consumes a month of tasks in an afternoon. Route the write to a different sheet, list or field, or add a filter that excludes records the Zap itself created.

Frequently Asked Questions

How long should I wait before deciding my Zap is not triggering?

One full polling interval for your plan, which is 15 minutes on Free, 2 minutes on Professional and 1 minute on Team and Enterprise. Anything shorter than that tells you nothing, because a polling trigger is silent between checks by design. Instant triggers are the exception and should appear within seconds, so an instant trigger with an empty history after a minute is a real signal rather than a timing artefact.

Why does my Zap work when I test it but not on real data?

Testing and running often take different routes. For many instant triggers the live event arrives as a webhook the app pushes, while the editor sample is pulled back through a separate API request, and the two return differently shaped data. A Zap mapped against the sample then references fields that never arrive in the real payload. Rebuild the mappings from a real run instead of the sample, and re-copy the webhook URL from the current version of the Zap.

Will turning my Zap off and on again fix it?

Often, because it resets the trigger connection and re-subscribes any webhook. It is Zapier’s own suggested step for a Zap that stops with no errors. The cost is that it also rebuilds the deduplication table, so anything created while the Zap was off is absorbed into the new baseline and skipped permanently. Do it last, after you have read Zap history, not first as a reflex.

Why did Zapier turn my Zap off by itself?

Zapier disables a Zap that errors 95% of the time it runs once it has run more than 20 times in the past 7 days. Enterprise accounts get 72 hours of warning and Team accounts get 24, while Free accounts get none, which is why it usually looks like somebody switched it off manually. Fix the failing step before re-enabling, otherwise the same ratio rebuilds and it shuts down again.

Can I make a Zap run on records that already exist?

Not through the trigger. When a Zap is switched on, Zapier reads the existing items and stores their IDs as already seen, so they will never fire. Zapier’s Transfer feature exists for exactly this and pushes selected existing records through the Zap on demand. Duplicating the records in the source app to force a trigger works but leaves you with duplicate data to clean up afterwards.

Why does my Google Sheets Zap trigger for some rows and not others?

Almost always structure. Rows deleted from the middle renumber everything below them while Zapier waits for rows past the old maximum, so the refilled rows never register as new. Rows inserted anywhere other than the bottom are not treated as new either. Blank rows read as the end of the sheet, and a row holding only a formula is not blank to Zapier even though it looks empty. Turn the Zap off before restructuring, then re-test the trigger.

If you have worked through all ten and the Zap still sits silent, the problem has usually left Zapier entirely. An app that stopped writing records, an API that changed shape, a form that submits to somewhere other than where you think it does. Zap history showing genuinely nothing, after a manual poll also finds nothing, is strong evidence the trigger app never had the data to hand over in the first place.

Most of the automation work I get handed starts here, with a stack that looks configured and a workflow that quietly stopped weeks ago. It is rarely the automation platform that needs replacing. It is one assumption in the middle of the chain, and finding it is faster than rebuilding around it. The same pattern shows up in community notifications that never arrive: the software is working exactly as configured, and the configuration is describing something nobody intended.