Your automation failed. Here is the recovery plan.

What should happen when an automation fails?

Preserve enough information to investigate, make the failure visible to an owner, and recover only the unfinished work. Repeating every step blindly can create duplicate records, messages, or charges. A recovery plan defines which failures can retry, which need a person, and when the system stops trying.

Separate temporary failures from decisions

A brief service outage or rate limit may be suitable for a bounded retry with a delay. Invalid input, missing permission, or an ambiguous customer request usually needs correction or review. Set a maximum number of attempts and a final destination for unresolved records. Avoid an unlimited loop that keeps spending credits while nothing improves.

Make the owner and response expectation explicit: “Operations reviews the failed-intake queue each working morning” is more useful than “an alert will be sent.” Keep alerts free of unnecessary customer details.

Check for duplicate effects before replaying

Use a stable source-event identifier and track which important steps completed. Before creating a new record, check for one already created for that event. Before resending a message, inspect whether it was accepted. A timeout means you did not receive an answer; it does not prove that the destination did nothing.

For an illustrative onboarding flow, a folder may already exist even though task creation failed. Resume at the failed step or safely reuse the folder instead of creating a second client workspace.

Adapt the recovery controls to your platform

n8n’s execution documentation explains reviewing runs and retrying failed executions. Make documents incomplete executions for retaining unfinished runs when that setting is enabled. Zapier documents replay controls. Read the current behavior and plan limits for your account; these options are not interchangeable.

Official documentation reviewed October 13, 2026. We have not tested these controls in your workspace.

Write and rehearse a one-page runbook

1. Identify the failed record and the last confirmed successful step.
2. Pause the affected path if continuing could create harmful duplicates.
3. Correct the cause and inspect existing downstream records.
4. Retry one safe sample and verify the complete result.
5. Recover remaining records, document exceptions, and record the change.

Use the recovery worksheet. If you need a scoped repair, describe the failure and affected systems in a service inquiry; do not include credentials.