Zapier replay: failed steps or the entire run?

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Choose the recovery boundary first

Zapier distinguishes replaying errored steps from Zap history and replaying an entire run from the editor. Failed-step replay does not rerun successful steps. Filter and Paths are not replayed in that mode. An entire-run replay starts a new run, re-executes steps and evaluates Filter and Paths using the current published workflow. Successful replayed actions count toward task usage again. Replay is an attempt, not a guarantee of recovery.

Our recommendation is to inspect business outcomes before choosing either option. A failed technical status does not establish that no external write occurred. Record which action failed, which earlier actions completed and whether the destination can confirm the uncertain step.

A fictional onboarding failure

Assume a workflow creates a project folder, creates a task and then records an audit row. Folder creation succeeds, task creation succeeds and the audit write fails. If the only missing obligation is the audit row, a full rerun could create another folder and another task. The preferred recovery boundary should match the missing obligation, subject to the actual run's supported replay options.

Now change the example: the failure happens during task creation and the destination response is ambiguous. Search for the task by a stable onboarding reference before repeating the action. If it exists, investigate the remaining obligation; if it does not, document the evidence for a retry.

A recovery worksheet

Prepare before editing the Zap

Zapier documents restrictions on failed-run replay after substantial structural changes. Our operational advice is to capture the failed run's details and review replay eligibility before reorganizing steps. Do not assume a newly rearranged workflow can resume an old run in the same way.

1. Inspect the failing step and its input in history.
2. Reconcile completed or uncertain writes against destination records.
3. Check current replay eligibility, required connections and available task allowance.
4. Choose failed-step recovery or a deliberately reconciled whole-run reprocessing plan.
5. Recover one understood case and verify the destination before selecting more runs.

Account for routing and pending attempts

If a corrected earlier value would change eligibility, failed-step replay does not re-evaluate the filter or branch as a fresh business decision. Decide whether that event should be reprocessed under the current policy and handle already completed actions accordingly. Do not treat the two replay modes as interchangeable.

Before adding a manual retry, inspect any scheduled automatic attempts and assign one operator to the recovery decision. Keep the original and recovered event references together. This is our coordination recommendation to reduce ambiguous parallel recovery work; actual options depend on the run state.

Verify the business contract

For the onboarding example, accept recovery when one intended folder, one intended task and one audit record can be reconciled to the source ID. A new successful run is useful evidence, but it does not by itself prove older side effects were harmless. This procedure is a proposed exercise with synthetic data, not a measured replay test.