Zapier Not Working? How to Find and Fix the Real Cause

Something that ran fine for months has quietly stopped. The leads are not landing in your sheet, the invoices are not being filed, and nobody told you. That silence is the worst part, because by the time you notice, you have a backlog to clean up as well as a fault to find.

The temptation is to start editing. Rebuild the step, reconnect everything, try a different trigger. Resist it. Zapier records what happened on every run, and that record narrows five possible causes down to one in about a minute. Change things after you know what broke, not before.

Why is my Zap not working?

Zapier's own troubleshooting page splits this into five questions, and they are worth asking in order. Is the Zap turned on? Is it triggering? Is it returning an error? Do you have enough permissions in the connected app? And is it running but behaving in a way you did not expect?

Those five map onto very different fixes, which is why order matters. A Zap that is turned off produces no runs at all. A Zap that errors produces runs full of red. A Zap that duplicates data produces too many runs. Knowing which shape you have saves you from fixing the wrong thing.

How do you read Zap history?

Zap history is at zapier.com/app/history, and it is the fastest diagnostic in the product. Every run gets a status, and the status is the diagnosis. If there are no runs at all, your problem is the trigger. If there are runs with a status, the status names the fault.

Two of those catch people out. Safely halted looks like a failure and is not one, so a Zap full of halted runs is often working exactly as designed. On hold looks temporary and is not, because held runs sit there until you fix the cause and replay them yourself.

Why is the trigger not firing at all?

If Zap history is empty, the trigger never fired. Zapier documents five reasons for this, and the first one is the most common by a distance. Work down the list before you touch the steps themselves, because a rebuilt Zap with the same cause will fail the same way.

• The Zap is not turned on. Open it in the editor and check the switch at the top left. Zaps get switched off by people, by errors and by limits, and nothing about the editor looks different when they are.
• The data already existed. Zapier states plainly that a Zap will not trigger on existing data. It captures items created after the last poll, so records that were already there are invisible to it. Zapier Transfer is their tool for moving history.
• The app connection has a problem. Open the trigger step, then the Account tab, and confirm the right account is connected. Reconnecting from that dropdown fixes expired tokens and revoked access.
• The wrong trigger event is selected. This is the quiet one. A New Row trigger will not fire when an existing row is edited, which Zapier's community threads bring up again and again for spreadsheet and database triggers.
• The trigger options do not match your data. Check the Configure tab for folder, label, form or table settings that point somewhere other than where the new data lands.

Before you call it broken, check the clock. Polling triggers do not run instantly, and Zapier documents the interval by plan: 15 minutes on Free, 2 minutes on Professional, and 1 minute on Team and Enterprise. On a free account, a quarter of an hour of nothing happening is normal behaviour, not a fault.

Why are my runs on hold?

Held runs mean Zapier caught the data but refused to act on it. Nothing is lost, which is the good news. Zapier's held runs documentation lists six causes, and each one has a fix followed by a replay, so read the cause before you start replaying.

• Flood protection. Zapier holds the batch when a poll turns up 100 or more events at once. Their guidance is to add a delay after queue action, then replay.
• A disconnected app account. Reconnect the account, then replay the held runs.
• Your task limit. Upgrade, enable pay-per-task, or wait for the billing cycle to reset, then replay.
• Expired payment details. Update the payment method on the account, then replay.
• An app access policy. On Team and Enterprise accounts an admin can restrict an app. Ask them to allow it, then replay.
• Too many steps. A Zap can hold 100 steps including everything inside paths. Past that you split the workflow, and there is no replay for this one.

Why did Zapier switch my Zap off?

Zapier turns a Zap off by itself when it errors 95 percent of the time it runs and has run more than 20 times in the past seven days. It sends an email when this happens. If your inbox filters that email away, the Zap simply disappears from service without a word.

This is a sensible protection rather than a punishment. A Zap failing on every run is usually hammering a downstream app with bad requests, and stopping it protects both sides. Zapier's documentation also describes a grace period for Team and Enterprise accounts before the shutdown takes effect.

You can change the behaviour per Zap. In the editor, open the advanced settings and look for the error setting override, where the two documented options are turn off if errors occur, which is the recommended default, and keep running if errors occur. Use the second one only for a Zap you are actively watching.

What do the error codes mean?

When a step errors, the message usually carries an HTTP status code from the connected app. That number tells you whether the fault is your setup, your permissions or the other app having a bad day. Zapier's troubleshooting documentation maps the common ones.

The pattern is worth internalising. Codes in the 400s are almost always something you can fix in the Zap or in the app's settings. A 500 is the other service failing, and the right response is patience plus a replay rather than a redesign.

A ten minute triage you can run every time

Finding the cause before changing anything

1. Check the switch — Open the Zap in the editor and look at the toggle in the top left. If it is off, find out why it went off before you turn it back on.
2. Open Zap history — Go to zapier.com/app/history and filter to this Zap. No runs means a trigger problem. Runs with a status mean the status is your answer.
3. Read the newest failing run — Open it and expand the step that failed. The error message and its status code point straight at the cause.
4. Check the connection — In the trigger step, open the Account tab and confirm the right account is connected. Reconnect it if there is any doubt.
5. Confirm the trigger event — In the App and event tab, check the event matches what really happens in your app. New and updated are not the same thing.
6. Test with genuinely new data — Create a brand new record rather than editing an old one, then wait out your plan's polling interval before deciding it failed.
7. Fix, then replay — Once the cause is gone, replay the held or errored runs from Zap history so the backlog clears rather than sitting there.

Run that list and you will find the cause of most failures. But notice what the list is really made of. Every step is you, checking on a machine, because the machine has no way of telling you it stopped and no idea what it was supposed to achieve. It is the same reason we built Sistava around an assistant that reports back rather than a wire you inspect.

A different shape for the same work

A Zap is a set of instructions with no understanding of the goal. It cannot tell the difference between no new leads today and a broken connection, so it stays silent either way and waits for you to check.

That babysitting is the part we removed at Sistava. You hire an AI Employee and describe the outcome you want in plain English, and it figures out the steps, notices when something looks wrong, and tells you rather than going quiet. The job is the instruction, not the wiring.

What this checklist will not fix

Being honest about the edges saves you an afternoon. Some problems are outside the triage above, and no amount of reconnecting will touch them.

• Outages on the other side. If the connected app is having an incident, your Zap is a symptom. Check that app's status page as well as Zapier's.
• Missing history. Turning a Zap on does not go back and process what it missed while it was off. Held runs can be replayed. Data that never triggered cannot.
• Bugs that need support. Community threads show cases where Zapier staff escalated a duplicate-trigger problem to engineering with no fix available to the user. Sometimes the honest answer is to raise a ticket.
• Design faults. A Zap that works but produces the wrong result is not broken, it is wrong. That needs rethinking rather than repairing.

To be fair to Zapier, the diagnostics here are better than most automation tools ship. Zap history is genuinely detailed, the statuses are honest, and the help documentation names the causes instead of hiding them. The friction is not the tooling, it is that somebody still has to go and look. If you would rather that somebody was not you, Sistava is free to try before you move any real work across.

Sources

• Zapier Help, Zap is not working
• Zapier Help, Zap isn't triggering
• Zapier Help, How to troubleshoot errors in Zap workflows
• Zapier Help, How to troubleshoot held Zap or step runs
• Zapier Help, How Zap triggers work
• Zapier Help, Zap limits
• Zapier Community, My Zaps are triggering twice (community thread, escalated by Zapier staff)