An Automation Failure Log and Recovery Checklist You Can Reuse

An automation marked failed may have completed part of its job. A form submission might create a customer record and then fail while sending the confirmation. Running everything again could create a duplicate record or send a message twice. A useful recovery process starts by finding the last confirmed outcome.

You do not need an incident-management platform for a small workflow. One failure record, a clear owner, and a deliberate decision about retries are enough to make the next action less uncertain. The template below is designed for ordinary business automations and should be adapted to the tools involved.

Describe the expected result first

Write one sentence explaining the workflow in observable terms: “For each accepted inquiry, create one review task and notify the assigned reviewer.” Avoid describing success only as a green icon in an automation dashboard. The task and the notification are the outcomes you can inspect.

Then give each incoming item a stable reference, such as the form submission ID already supplied by the source system. Keep that reference with the resulting record where the tool allows it. It helps you connect the input, run history, and destination without matching vaguely similar names.

Our guide to automation ideas before hiring covers what to automate. This recovery record deals with what happens when a chosen workflow stops behaving as expected.

Copy this failure record

Store one record for each affected run or a clearly bounded group of runs. Keep the actual payload in an appropriately protected system; the log usually needs references and observations rather than a copy of every field.

• Workflow: [Name and link to its configuration]
• Observed at: [Date, time, time zone]
• Owner: [Person responsible for the next decision]
• Input reference: [Source event or submission ID]
• Run reference: [Automation run ID and history link]
• Expected result: [Specific records or messages that should exist]
• Confirmed completed: [Steps verified in the destination, with links]
• Failed or uncertain: [Step, visible error, and what remains unknown]
• Affected scope: [Known items and the time range checked]
• Containment: [Paused step, held inputs, or reason no pause is needed]
• Recovery decision: [Resume, limited replay, manual completion, or investigate]
• Duplicate check: [How an existing result was identified]
• Verification: [Destination checks and the person who performed them]
• Next review: [Time or event that will trigger another check]

A status of unknown is useful. It tells the next person where evidence is missing. Replacing unknown with failed can encourage an unnecessary replay; replacing it with complete can hide unfinished work.

Contain the problem without losing incoming work

Decide whether new runs could repeat the same problem. If they can, pause the relevant workflow or step using the product's documented controls. Record where new inputs will wait and how they will be recovered. A pause that silently discards fresh submissions may create a second problem.

For example, keep the source form active if submissions remain available there, while holding the downstream action that is producing duplicate tasks. This is an example, not a universal instruction: check what your particular trigger does during a pause before changing it.

Tell the affected operator what outcome is delayed, where the source items remain, and when you will check again. A short operational message is more useful than forwarding an unexplained stack trace.

Inspect the destination before retrying

Open the destination record using the input reference. Check whether the intended action happened, whether it happened more than once, and whether a later step is still outstanding. A timeout in the automation history does not by itself prove that the receiving service did nothing.

AWS's explanation of safe retries describes idempotency: arranging a repeated request so it does not create an additional effect. In a business workflow, the practical question is whether the specific action or integration actually provides that protection. Do not infer it from the presence of a retry button.

If the tool documents a safe resume from the failed step, evaluate that route. If it only replays the whole workflow, account for every earlier action before using it. When behavior is unclear, hold the replay and complete a narrow, verified repair or seek the product's guidance.

Walk through one concrete failure

Suppose submission Q-104 should create one review task and send one internal notification. The task exists and contains Q-104, but the notification step failed. Record the task link under confirmed completed. Check notification history before deciding whether another message is needed.

If no message exists and the tool supports retrying only that step, recover that step and inspect its result. If a full replay is the only option, do not assume the existing task will be reused. The workflow may need a lookup or another documented duplicate-prevention mechanism before replay becomes appropriate.

Keep the example bounded to this submission. After it works, list the other affected references and repeat the destination checks. One repaired item is evidence about that item, not proof that an entire backlog has recovered.

Close the record with evidence

Verify the final records and messages, then check a new ordinary input through the workflow. Record what changed and what observation would show the problem returning. If nothing was changed because the cause was temporary, document that decision and the next review point.

Choose one follow-up improvement: retain the source reference, add a clearer error notification, separate an irreversible action, or document the retry behavior. Put the improvement where it has an owner. Keep the completed failure record linked from the workflow so the next interruption begins with evidence instead of another round of guesswork.