Before you retry a failed automation, check what already happened.

A workflow errored. Something did not arrive where it was supposed to, and the retry button is right there. Do not press it yet.

A failed run has rarely done nothing. It has usually completed some steps before stopping, and those completed actions may still exist in the systems they touched.

Imagine a five-step order workflow: add a row to a sheet, send a confirmation, create a CRM record, notify the team, then charge the card. If step four fails, the earlier row, email, and CRM record may already exist. Replaying from the wrong point can repeat them. If the failure is a timeout, the uncertain action may also have succeeded even though the automation never received the acknowledgment.

1. Freeze the trigger

If the workflow is still receiving new events, the evidence changes while you investigate it. Pause or deactivate the workflow so you can work from a stable set of runs.

Pausing does not necessarily cancel upstream delivery. For example, Stripe documents that it retries failed webhook deliveries for up to three days in live mode. Pausing gives you room to investigate; it does not guarantee a clean slate.

2. Find the last step that succeeded

Open the failed execution itself, not only the dashboard summary. Walk through the run in order and identify the last step that returned a successful result. Compare its output with the same step in the last known good run.

The red step is not always the original cause. A field may have changed shape one step earlier, an array may be empty, or a mapping may now resolve to nothing. A clear rejection and a timeout are also different: a timeout means the destination may have acted even though the response never arrived.

3. Check the destination directly

Do not use the automation log as the only record. Check every system that received an action: the email provider’s sent log, the sheet row, the CRM record, or the payment processor. Search with the event, order, lead, or submission identifier.

Make a short list with two columns: completed and not completed. Treat a timed-out action as potentially completed until the destination proves otherwise.

4. Confirm what “retry” means on your platform

Make: an incomplete-execution retry starts with the module that caused the error. Make also documents automatic retry for some temporary errors and a separate Retry error handler. Those are related features, not identical settings.

n8n: the execution screen offers “Retry with currently saved workflow” and “Retry with original workflow.” Both use the previous execution’s data; the difference is whether later workflow edits are included. The public documentation does not promise that earlier side effects will be skipped.

Zapier: Zapier separates errored runs from held runs. Its duplicate-data guidance warns that replaying a timed-out action may create duplicate data. Check Zap history and the destination first.

Webhook providers can retry independently. Stripe says event ordering is not guaranteed and the same event may be delivered more than once. Record processed event IDs and skip duplicates.

5. Choose replay, manual completion, or no action

If you cannot determine which option is safe, do not guess with high-consequence actions. Verify payments, customer messages, deletions, and public posts manually before taking another action.

6. Make the next failure cheaper

• Put irreversible actions last. Send, charge, delete, or publish after reversible preparation.
• Deduplicate on an identifier you control. Record a processed event, order, or submission ID.
• Prefer upserts to creates. Find or create, then update, is usually safer to repeat.
• Acknowledge webhooks quickly. Return success before slow downstream work where the provider recommends it.
• Alert on failure. A failure found today is an incident. The same failure found weeks later is an audit.

A practical example

A form-to-CRM workflow times out while creating a contact, and the team notification never runs. Pause the workflow. Search the CRM by submission ID or email. If the contact exists, the write worked and only the acknowledgment was lost. Send the missing notification manually, document what happened, and change the CRM action to find or create by a unique key before retrying.

When you still cannot tell

Rank the ambiguous action by consequence. Repeat a low-risk internal step only when the downside is acceptable. For payments, customer messages, deletions, and public posts, confirm manually. Record what you could not verify; an outcome you cannot reconstruct is a logging gap.