A Retry Needs New Evidence

Automation makes repetition cheap. That is useful when a temporary network interruption clears or an upstream service recovers. It is dangerous when the same request, input, and adapter keep meeting the same failure. The system can produce a great deal of activity without getting any closer to a result.

A useful retry starts by classifying the failure. Was the problem temporary, such as a timeout? Was the input incomplete? Did the external interface change? Did a control deliberately stop the action? Those cases need different responses. Treating all of them as “try again” turns diagnosis into noise.

I use a simple standard: before another attempt, identify the evidence that makes success more likely now. The service is healthy again. The missing field has been supplied. The selector or adapter has been corrected and tested. The blocked condition has been resolved. If nothing relevant changed, another attempt is usually just another copy of the same failure.

This matters most when automation touches an external system. Portals, APIs, and vendor interfaces change outside the workflow's control. A bounded attempt budget and a cooldown protect the service, the account, and the integrity of the operating record. They also force the system to surface a real blocker instead of hiding it behind an endless loop.

The evidence should stay with the retry. Record the failure category, what changed, what was tested, and the result of the next attempt. That creates a decision trail a person can review and gives future automation a better basis for deciding whether to proceed, wait, or escalate.

A good recovery path is not defined by persistence alone. It is defined by changed conditions, controlled attempts, and a clear handoff when the system no longer has enough evidence to act safely.

Reliable automation does not prove itself by refusing to stop. It proves itself by knowing what must be true before it tries again.