Why Your Zap Turned Off by Itself and How to Fix It
How-to — — by Mahmoud Zalt
Zapier switches a Zap off at a 95 percent error rate. The exact rule, where to find the errors behind it, and the settings that change it.
You did not touch it. Nobody on the team touched it. Yet there it is in the dashboard, switched off, with a week of work that never happened sitting behind it. The instinct is to flip it back on and move on with your day.
Do not do that yet. Zapier does not switch Zaps off at random, and the rule it follows is specific enough to work backwards from. Turning it on without fixing the cause usually means it turns itself off again within the week, only now you have lost more time.
What is the exact rule?
Zapier documents two conditions together. Your Zap turns off automatically if it errors 95 percent of the time it runs, and it has run more than 20 times in the past seven days. Both parts matter. A Zap that fails every time but only runs twice a week does not hit the threshold.
That design is deliberate and, honestly, in your favour. A Zap failing on nearly every run is usually sending bad requests to a downstream app over and over, and burning your attention along with everyone else's. Stopping it is protection, not punishment.
What else turns a Zap off?
The error ratio is the documented rule, but it is not the only way a Zap stops. Zapier's own page on a Zap not running names three more, and each has a different fix. It is worth checking these before you go hunting for errors that may not exist.
- A feature your plan no longer covers. Zapier states it holds actions using premium features that are not included in your current plan. A community Solution Partner named a trial expiring or a plan downgrade as a frequent trigger for exactly this.
- Your task limit. Reaching the plan's task limit for the billing cycle causes runs to be held rather than executed. Zapier's fix is to upgrade, or wait for the reset, then replay.
- An app access policy. On Team and Enterprise accounts, an admin can restrict or prohibit an app. Zapier's guidance is to ask the admin to update the setting, or swap in an approved app.
- Edits to the trigger or an action. Community responders report Zaps switching off after configuration changes. That is a community observation rather than documented behaviour, but it is worth ruling out if the timing lines up with an edit.
Where do you find the errors that caused it?
Zap history at zapier.com/app/history is the only honest record. Filter to the Zap, look for runs with an errored status, and open the newest one. Expand the step that failed and read the message, because it usually carries an HTTP status code that names the fault.
Move quickly, though. In a community thread about a high error ratio shutdown, a Zapier Community Manager said they can only guarantee a maximum of one month of Zap run data in Zap history. The user in that thread was investigating a June shutdown in November and the logs were simply gone.
| Code | What it means | Documented fix |
|---|---|---|
| 401 | The connection is no longer authenticated | Reconnect the app account |
| 403 | The account lacks permission | Confirm the connected account has the access it needs |
| 404 | The record was not found | Check whether the record still exists in the app |
| 422 | The data was the wrong shape | Check field formats and required values |
| 429 | You hit a rate limit | Slow the workflow and review Zapier's rate limits |
| 500 | The other app had a server error | Replay the failed runs, or turn on Autoreplay |
A 401 running on every single run is the classic auto-shutdown story. A connection expired, every run failed, the ratio crossed 95 percent, and the Zap went dark. That one is a two-minute fix once you have seen it.
Can you stop it turning off?
Yes, per Zap, and you should think carefully before you do. Zapier documents an error setting override in the Zap's advanced settings, reached by opening the Zap in the editor and clicking the advanced settings icon in the left sidebar.
The two documented options are turn off if errors occur, which is marked as recommended, and keep running if errors occur. The second one is meant for a workflow you genuinely cannot afford to have paused, and it comes with the obvious cost: nothing will stop a broken Zap from failing indefinitely.
Autoreplay is the gentler companion setting. Zapier documents it on Professional, Team and Enterprise plans, retrying errored runs automatically so a passing outage does not push your ratio into shutdown territory. Its per-Zap override offers your default account settings, always replay, or never replay.
Getting it running properly again
From switched off to genuinely fixed
- Read the shutdown email — It names the Zap and the reason. If you cannot find it, check spam and any rules that file Zapier mail away.
- Open Zap history for that Zap — Filter to errored runs and open the most recent. Do this early, since run data is only guaranteed for about a month.
- Read the failing step — Expand it and note the error message and status code. That is your actual fault, not the shutdown.
- Fix the cause — Reconnect the account for a 401, adjust permissions for a 403, correct the field mapping for a 422, and check the app's status page for a 500.
- Check your plan covers every step — If a trial ended or the plan changed, a premium step may now be unavailable. Zapier holds those actions rather than running them.
- Turn the Zap back on and test — Create genuinely new data and watch the run go green in Zap history before you trust it.
- Replay what was held or errored — Select the runs in Zap history and replay them. Remember that replays create new runs which count toward task usage.
There is a bigger point buried in that error ratio rule. Zapier has to guess whether a failing Zap should keep going, because it has no idea what the Zap was for. It cannot tell an urgent customer workflow from a nice-to-have report, so it applies one blunt threshold to both. Handing the goal to the worker instead of the wiring is the whole idea behind Sistava.
When the worker knows what it is for
You hire an AI Employee and tell it the outcome in plain English. When something fails it can tell you what failed and why, try a sensible alternative, or stop and ask, because it knows the point of the task rather than just the next step. The capability list is on the Sistava feature pages.
What this will not fix
A few of these shutdowns land outside what you can do from the editor. Recognising them early stops you rebuilding something that was never the problem.
- Errors that already aged out. If a Zapier Community Manager's note about roughly one month of run history holds, an old shutdown may have no evidence left. Fix forward, add notifications, and move on.
- The work that never ran. Turning a Zap back on does not process what happened while it was off. Held runs can be replayed. Triggers that never fired cannot.
- Plan-level restrictions. If a step needs a feature your plan no longer includes, no setting in the editor restores it. That is a billing decision.
- A Zap that is simply wrong. Keeping a broken workflow running with the error override does not make it work. It only makes it fail more quietly.
Zapier deserves credit here. Publishing the exact threshold, emailing when it fires, and giving you a per-Zap override is more openness than most tools offer about their own safety valves. The awkward part is that the valve exists at all, because it exists to protect you from a workflow that cannot tell it is failing. If that trade sounds like the wrong one, Sistava is free to try on a single real task.
FAQ
Why did my Zap turn off by itself?
Zapier turns a Zap off automatically when it errors 95 percent of the time it runs and has run more than 20 times in the past seven days. An email notification is sent when this happens. Zapier also holds or stops Zaps that use premium features your plan does not include, that hit the account task limit, or that use an app restricted by an admin.
How do I stop Zapier turning my Zap off?
Open the Zap in the editor, click the advanced settings icon in the left sidebar and find the error setting override. The two documented options are turn off if errors occur, which Zapier marks as recommended, and keep running if errors occur. Use the second only for a workflow you are actively watching.
Where do I see what errors caused the shutdown?
Zap history at zapier.com/app/history. Filter to the Zap, find runs with an errored status, and open the most recent one to read the message on the failing step. Act quickly, because a Zapier Community Manager has said in a public thread that they can only guarantee a maximum of one month of Zap run data.
What is Autoreplay and will it help?
Autoreplay automatically retries errored runs and is documented on Professional, Team and Enterprise plans. It helps when the errors come from short outages on the other app, because the retries succeed and the error ratio never climbs. It does not help when the cause is a permanent fault like an expired connection.
Can I use both an error handler and Autoreplay?
No. Zapier documents that once you publish a Zap with an error handler, Autoreplay turns off for that Zap so error handling can take over, and that you cannot manually replay Zap runs which have error handlers. Choose one approach per Zap.
Will turning the Zap back on process what it missed?
No. Runs that were held can be replayed from Zap history, and Zapier notes that replaying creates new runs which count toward task usage. But data that never triggered the Zap while it was off is not queued anywhere and will not be picked up.
Sources
- Zapier Help, Zap is not running
- Zapier Help, Decide how your Zap handles errors with advanced settings
- Zapier Help, How to troubleshoot errors in Zap workflows
- Zapier Help, Replay failed Zap runs
- Zapier Help, Set up custom error handling
- Zapier Community, Zap was stopped due to high error ratio (community thread with a Zapier Community Manager reply)
- Zapier Community, Zap keeps turning off but doesn't error (community thread)