Do Zap Replays and Error Handlers Use Tasks?

Three recovery mechanisms compared

Why an errored action isn’t a task — but a successful retry is

Zapier’s task-usage documentation is explicit that all action steps that error or halt do not count toward task usage, and that all steps that don’t run — because a previous filter blocked them or the Zap errored upstream — don’t count either. That’s the baseline every recovery mechanism in this article builds on: an attempt that fails costs nothing by itself.

What changes the total is what happens next. The same documentation lists previously successful billable steps that run again during a full replay and successful billable steps within an error-handler path as things that count. Recovery does not create a billing exemption: an ordinary action that succeeds is one task, while products with nonstandard rates keep their applicable documented rate.

Full-run replay: 2 original + 2 replay = 4

Replaying an entire Zap run from the editor is a different mechanism from errored-step replay. Zapier creates a separate new run and replays every step starting with the trigger, regardless of that step’s status in the original run. Filter and Paths steps are re-evaluated using the currently published version of the Zap, not the version that existed when the original run happened.

Synthetic model: a Zap with two ordinary successful actions, no errors, replayed in full after the fact.

Original run: 2 successful ordinary actions = 2 tasks
Full replay: same 2 actions succeed again = 2 tasks
Total across both runs: 2 + 2 = 4 tasks

The trigger itself is zero-task in both runs — triggers never count under the documented rule — so all four billed tasks come from the two action steps succeeding twice each. This is simple arithmetic built directly from the documented “steps that rerun during a full Zap replay” rule, not an observed account result; a real full replay against a changed Zap could re-evaluate Filter or Paths conditions differently and produce a different outcome.

For a production estimate with more actions or branches, use MetaFlowKit’s Automation Usage Calculator and model the original and replay as separate successful-run volumes.

Error-handler path: 0 + 0 + 1 + 1 = 2

Custom error handling splits a Zap into two paths at the protected step: a Success path that runs when no error occurs, and an Error path that runs only when that specific step errors. The original errored step itself still does not count toward task usage under the standard rule — the error-handler path is what runs next, and its own steps are billed individually.

Synthetic model: one ordinary action errors, triggering an error-handler path containing a Formatter step, then a Slack notification, then a ticket-creation action.

0 originating errored action (never billed)
+ 0 Formatter step in the handler path (task-free app)
+ 1 Slack notification (succeeds)
+ 1 ticket creation (succeeds)
= 2 tasks for the recovery path

This estimate assumes both the notification and ticket-creation steps succeed; if either errors instead, it drops out of the total under the same errored-steps-don’t-count rule that applies everywhere else in this article.

The task-free Formatter in this model follows the same current exemption covered in the Zapier Filters, Paths and Formatter task guide; the two ordinary recovery actions are the billable part.

Error ratio versus task usage

It’s worth keeping two separate Zapier concepts apart here. Custom error handling documentation notes that when an error handler runs, the original errored step does not count toward the Zap’s error ratio — a reliability metric Zapier uses to decide whether a Zap should be automatically turned off for erroring too often. That’s a different measurement from task usage. The task-usage rule that an errored step bills nothing exists independently of the error-ratio exemption; one is about billing, the other is about whether your Zap stays turned on. Don’t treat the error-ratio exemption as the reason the errored step is free — it’s free under the ordinary task rule regardless of error-ratio accounting.

Autoreplay interaction and replay limitations

Publishing custom error handling on a Zap turns off Autoreplay for that specific Zap — account-wide Autoreplay settings for your other Zaps are not affected. Runs that use an error handler also can’t be manually replayed from Zap History the way an ordinary errored run can; a full Zap run replay is the available alternative for those runs. These are documented interaction constraints, not something to infer from general error-handling behavior, and they’re worth rechecking close to publication since replay features have changed more than once.

Duplicate-side-effect and stale-data risks

A full Zap replay repeats every step that succeeds, which means any external action that already completed successfully in the original run can run again — sending a second copy of an email, creating a second record, charging a second payment. This is a direct consequence of the documented “steps that rerun during a full Zap replay” behavior, not an edge case. Before replaying an entire run, inspect what the original run actually did in Zap History, decide whether the narrowest available recovery mechanism (errored-step replay, or an error handler) would achieve the same fix without repeating already-successful actions, and verify whether the destination systems involved are idempotent — meaning a repeated request produces the same end state rather than a duplicate one. None of that idempotency behavior is a Zapier guarantee; it depends entirely on how the connected app handles a repeated write, so treat it as operational guidance to verify per app, not a platform assurance.

Verification checklist

• Use Zap History’s related-runs view to see the original run alongside any replays and confirm which steps actually ran in each.
• Check each step’s individual run status — success, errored, safely halted — rather than relying on the overall run status alone.
• Cross-check your estimated task total for a replay against the account’s actual Task usage figure for that time window.
• For error-handler Zaps, confirm in the Zap’s settings whether Autoreplay is off, since publishing a handler disables it for that Zap automatically.

Common counting mistakes

• Assuming any replay is “free” because the original error was free — a successful replay bills under the ordinary action rule.
• Assuming errored-step replay and full-run replay are the same mechanism; only the full-run version re-runs already-successful steps.
• Forgetting that a full replay re-evaluates Filter and Paths against the currently published Zap, which can change which steps even run compared to the original.
• Treating the error-ratio exemption for handled errors as if it were the reason the step is task-free — the task rule and the error-ratio rule are separate.
• Trying to manually replay a specific run that used a custom error handler, instead of using the documented full-run replay alternative.

FAQs

Does an errored action step ever count as a task?

No, under the current documented rule, an action step that errors or is safely halted never counts toward task usage, regardless of which recovery mechanism is used afterward.

If I replay just the errored step and it succeeds, is that billed?

Yes. A successful replayed step counts as an ordinary successful action under the standard one-task rule, even though the original failed attempt did not count.

Does a full Zap replay re-bill steps that already succeeded once?

Yes. Full-run replay creates a new run and re-runs every step from the trigger; any billable action that succeeds again counts again, even if it already counted in the original run. Triggers and documented task-free controls remain exempt.

Can I manually replay a specific run that has a custom error handler attached?

No. Runs that use an error handler can’t be manually replayed from Zap History; replaying the entire Zap run is the documented alternative.

Does the original errored step’s exemption from the error ratio mean it’s exempt from task billing too?

They’re separate rules that happen to produce the same free outcome for the errored step. The error-ratio exemption affects whether the Zap gets auto-disabled for erroring too often; the task-billing rule is the general “errored steps don’t count” rule that applies regardless of error handling.