Retries are not recovery
Pressing retry can repeat the original damage. Reliable workflows know what already happened, what remains unfinished and how to resume safely.
When an automation fails, the most tempting response is also one of the most dangerous: run it again.
Sometimes that works. Sometimes it sends the same customer message twice, creates another record, charges the same card again or publishes a duplicate post.
A retry repeats an instruction. Recovery understands what happened.
The missing question
Before restarting a failed workflow, the business needs to know which steps completed, which steps failed and which results already reached the outside world.
A red error message rarely tells the whole story. The workflow may have saved the record but failed while updating the dashboard. It may have published the post but timed out before confirming the link. It may have sent the email but failed to mark the contact as complete.
If the system starts again from the beginning, it can repeat the part that already succeeded.
Reliable recovery has memory
A recoverable workflow keeps a clear record of each meaningful action. It can recognise the same job when it appears again, check the destination and continue from the first unfinished step.
That record does not need to be complicated. It needs to answer four questions:
- What was the intended result?
- Which actions were attempted?
- What can be verified at the destination?
- What is the next safe action?
Without these answers, a retry is guesswork.
Check the destination, not only the workflow
Internal status is not enough. A button can stay on “sending” after the message arrived. An uploader can show an error after the media was accepted. A scheduling screen can look saved while the post never entered the queue.
Recovery depends on checking the place where the result should exist. Look for the customer record, public post, scheduled item, payment or sent message before repeating the action.
This is the difference between activity and evidence.
Design for interruption
Workflows should expect browsers to close, connections to drop and tools to return unclear responses. Each important step should leave enough evidence for the next run to understand where to resume.
The workflow should also have a safe waiting state. When the evidence is incomplete, it should pause rather than repeatedly push the same action.
A practical recovery rule
Use this order whenever an automated process stops:
- Identify the intended business result.
- Inspect the destination for proof of completion.
- Compare that proof with the workflow record.
- Resume only the unfinished step.
- Verify the final result before closing the task.
This approach may feel slower than pressing retry. It is much faster than cleaning up duplicate messages, records, charges or posts.
Retry less. Recover better.
Reliable automation is not defined by never failing. It is defined by failing without losing track of reality.
A retry says, “do it again.” Recovery says, “find out what happened, then finish safely.”
