A Zap stopped or shows Errored or Halted: what each status means and what to replay

Read the status before you touch the Zap

Zapier's troubleshooting article separates runs that errored from runs that were safely halted. An errored run hit a problem and did not finish. A safely halted run stopped on purpose, usually because a search step found nothing, and halted runs do not cause the Zap to switch off. The article also names other statuses you will meet in Zap history.

• Errored: the run did not finish because of a problem, such as a rejected value or an expired connection.
• Safely halted: the run stopped deliberately, often because a search found no match.
• On hold: the run is paused, for example because an app is disconnected or a task limit was reached.
• Handled error: a custom error handler took over the run.
• Scheduled: the run errored and Autoreplay will try it again.

Why a Zap can switch itself off

Zapier states that a Zap will turn off automatically if 95% of its runs result in errors in the last 7 days. The article describes warning emails and a grace period for Team and Enterprise accounts. The practical effect is that a Zap with one broken step can go quiet without anyone choosing to stop it, and then nothing runs until someone notices.

A Zap that is off is not collecting anything. Zapier's trigger documentation says a Zap does not fire for data created in the app before it was turned on, which means records created while a Zap was off may need separate handling when you turn it back on. Decide how you will catch up before you switch it back on, rather than after.

• Check whether the Zap was switched off by Zapier, by a colleague or by an error rate.
• List what happened in the source app while the Zap was off.
• Fix the cause of the errors before switching on; otherwise the error rate can climb again.

Replay and Autoreplay: what each repeats

Zapier's replay article says replay from Zap history retries only steps that errored, and leaves successful steps alone. Replaying a whole run from the editor re-runs every step, starting with the trigger, whatever each step's earlier status, and bills the tasks again. A replay must happen within 60 days of the initial trigger event, and it fails if you have added, removed or moved steps since. Zapier also says it cannot guarantee a replay will succeed.

Autoreplay retries an errored step up to five times. The article gives the gaps as 5 minutes, 30 minutes, 1 hour, 3 hours and 6 hours, so the last attempt lands about ten and a half hours after the first error. It is meant for temporary problems such as a short outage. For an error you have already fixed, a manual replay recovers the data.

• Use history replay for a fixed errored step, after checking the destination for a half-finished record.
• Use full-run replay only when every step should run again.
• Plan features differ: autoreplay and full-run replay need a paid plan.

Why the alert can be late or missing

With Autoreplay on, Zapier holds back error emails and Zapier Manager triggers until the final attempt fails. A person waiting for an email about a broken Zap may therefore hear about it hours after it first failed. A custom error handler changes this again: publishing a Zap with error handling turns that Zap's autoreplay off, and no error notification email is sent when a handler runs. The handler must send its own alert, and a failure inside the handler needs its own check.

None of this is a fault. It means that who is told, and when, depends on settings that someone chose once and may have forgotten. A named alert route with a test is the only way to know it works.

• Find out whether each important Zap uses Autoreplay, a custom handler or neither.
• Send a test failure on a copy and see who receives what, and when.
• Use a shared mailbox, so the alert does not depend on one person.

A Zap that stops without any error

If a Zap simply stops triggering and shows no errors, Zapier's trigger documentation suggests turning it off, waiting about a minute and turning it on again, which resets the trigger connection. It also warns that sample records shown while building can differ from live data, and that large bulk results, for example from a data migration, may be held for review rather than run at once. These explain some quiet Zaps without any fault in the Zap's steps.

If you have to guess whether a Zap is healthy, compare the number of source records with the number of runs for a day you can check by hand. A gap that grows is a trigger problem, not an action problem.

What this guide does not cover

This guide helps you read what happened. It does not fix a Zap, recover records from a live replay or promise that an alert will arrive. The paid outcome for alerts hooks up a shared alert for up to five named automations and proves it with a deliberate failure on a copy. A standing service watches named automations and prepares corrected copies for you to switch on. Neither includes round-the-clock cover or a response-time guarantee.