Retries, Duplicate Actions and Failed Runs in AI Automation

Short answer: a failed run is only safe to retry if you know whether the external write already happened. Most duplicate invoices, double emails and repeated charges come from one of three situations:

• a retry after a write that actually succeeded;
• a full re-run that repeats steps that had already worked;
• a trigger that fired twice.

Before turning on automatic retries, give every write step a way to recognize work it has already done. Examples are an upsert by a stable key, a search before create, or a reference number the destination rejects when it sees it twice. Then learn exactly what each platform re-runs:

• Zapier replays only the errored steps by default. Its "replay entire Zap run" option repeats everything, including the trigger.
• Make keeps failed runs for retry only if you turn on incomplete executions, which are off by default.
• n8n retries individual nodes with Retry On Fail and lets you re-run failed executions from the executions list.

Trace one failed write

Everything in this example is invented. A workflow receives a paid order, creates an invoice in the accounting app, and then emails the invoice to the customer. Here is what can go wrong at the invoice step, and what a retry does in each case.

Case 2 is the dangerous one. A timeout tells you the platform did not get an answer, not that the write failed. Zapier's guidance for "The app did not respond in time" is to replay or rely on autoreplay. That is safe only when the write step can detect an invoice it already created.

What each platform re-runs

What happens when an action meets a duplicate depends on the destination app, not the platform. Zapier documents four outcomes: the app creates a duplicate record, returns an error, updates the existing record, or ignores the duplicate. Test your destination before relying on any of them.

Settings to check before you trust retries

Zapier

• Decide whether autoreplay should be on account-wide, or only for Zaps whose write steps can detect earlier work. Per-Zap Never replay is available.
• Avoid "replay entire Zap run" for Zaps that create records, send messages or charge cards, unless the first steps can tell they already ran.
• If several Zaps use the same form or webhook, assume each one will run.

Make

• Turn on Store incomplete executions for any scenario that writes to another system, so a failure keeps its data.
• Size the incomplete-executions allowance and check Discard data if storage is full: with it on, a full folder silently discards failed data; with it off, the scenario is disabled until you make room.
• Use Process data in order (formerly Sequential processing) when order matters. New runs then wait until incomplete executions are resolved.
• Know that Rollback does not undo writes to apps like accounting or email.
• For instant-trigger scenarios, have someone watch for deactivation after the first error.

n8n

• Put Retry On Fail only on nodes that are safe to repeat, such as reads and upserts, not on create or send nodes without a check.
• Use On Error: Continue (using error output) to send failures to a clean-up or review path instead of stopping silently.
• Set an error workflow for every production workflow.
• Retry failed executions before execution data is pruned, and keep your own record of anything you may need later.

Make every write recognize work it has already done

Platform settings decide when a step runs again. Only the write step can decide whether running it again is harmful. In order of preference:

1. Upsert by a stable key. Update the record if it exists, create it if not. For document and record pipelines, see AI document extraction to sheets or CRM, which uses a compound key.
2. Search, then create. Look up the order reference in the destination. Create only if nothing is found, and store the new record's ID.
3. A reference the destination rejects twice. Some APIs accept a unique reference or idempotency key and refuse a second request with the same key. Check your destination's API documentation.
4. A sent-log for messages. Before sending an email or message, check a log keyed by order and template. Write to the log only after the send succeeds.

What retries cost

Retries are not free. On Zapier, replaying an entire run counts its successful steps as tasks again. On Make, retried modules run again, so check how they count against your credits. On n8n Cloud, check how re-run executions count against your monthly executions. Budget an allowance for failures. For example, if 3% of 2,000 monthly orders fail and each is retried twice, plan for about 120 extra runs. That figure is illustrative. See AI workflow automation pricing explained for how each meter works.

Recovery checklist for a failed write

1. Stop automatic retries for the affected workflow if duplicates are possible.
2. Check the destination for the record or message, using the business reference, not the platform's run ID.
3. If it exists, mark the run resolved and replay only the steps after the write.
4. If it does not exist, replay the failed step.
5. If several runs fired for one event, keep the first record, cancel or reverse the others in the destination, and find the duplicate trigger.
6. Record what happened and change the write step so the same failure cannot create a duplicate next time.

Who should not turn on automatic retries yet

• Workflows that charge cards, issue refunds or send customer messages without a duplicate check on the write step.
• Teams that cannot see the destination. If nobody can search the accounting app or CRM to confirm what happened, every retry is a guess.
• Scenarios where the failed data is not stored. Turn on failed-run storage first, then retries.

For broader platform tradeoffs, see AI workflow automation platforms compared.