An automation says the request timed out. You press Retry, and two customer records appear.
The first attempt may have reached the destination and created the record before the reply was lost. From the automation’s side, the result was uncertain. Treating that uncertainty as proof that nothing happened is what made the second attempt dangerous.
Keep “unknown” as a real outcome
For a step that changes another system, distinguish a confirmed success, a confirmed failure with no change, and an unknown outcome. A timeout often belongs in the third category until the destination or a reliable operation record resolves it.
The wording in a dashboard can hide this distinction. “Failed run” might mean the workflow didn’t finish, while an earlier step already created a record or sent a message. Replaying the whole workflow can repeat that earlier action.
My first move would be to inspect the destination using the original request’s reference. If there is a matching record, confirm that it belongs to this action and that the relevant fields are correct. If the system offers an operation-status lookup, use its documented process. An immediate empty search may still be inconclusive when records take time to appear.
Give the business action an identity
A retry is another attempt to perform the same business action. It shouldn’t silently become a new action just because a new run started.
Some APIs support an idempotency key: a stable identifier that lets the receiving system recognize repeated attempts. Stripe’s idempotent request documentation, for example, describes returning the saved result for a repeated key under its documented conditions. It also defines limits around parameters and key retention. That behavior belongs to that API; sending a made-up header to an unrelated service doesn’t create the same protection.
Ask your developer what identifies one action, where that identity is stored, and how long duplicate protection lasts. A later, genuinely separate request needs its own identity. Reusing one key for every customer inquiry could suppress legitimate work just as surely as generating a new key on every retry could duplicate it.
Account for repeated events and simultaneous attempts
Even a workflow you never manually retry can receive the same event more than once. Stripe’s webhook guidance explicitly discusses duplicate events and recording processed event identifiers. Other providers have their own delivery rules, so check the documentation for the actual source.
A simple “search, then create” sequence also has a gap: two workers can both search before either creates the record. Both see nothing and both proceed. The protection needs to hold when attempts overlap, using capabilities the destination or integration actually supports, such as a properly enforced unique operation identifier.
This is why a promise that an automation “checks for duplicates” needs an acceptance test. Ask what happens during concurrency, after a timeout, and after the provider’s duplicate-recognition window expires. Don’t assume universal exactly-once behavior.
Test uncertainty without creating a live business problem
Use a sandbox or an isolated workflow with harmless sample data and outbound actions disabled. Confirm the isolation first, especially for payments, messages, bookings, or inventory changes.
Have the maintainer demonstrate a normal request, a repeated attempt for that same action, and two overlapping attempts. Where the test tools support it, simulate losing the response after the destination accepts the action. Check the actual destination records and the workflow’s stored outcome, not just its green completion indicator.
Keep the action reference, attempt times, destination record ID, and resolution together. If a live result remains unknown, pause repetition and give that evidence to the system owner or provider. For existing duplicates, confirm which records and downstream actions are involved before deleting anything.
The same distinction belongs in approval gates for AI website work: permission to act doesn’t prove that an attempted action completed once. Put the observed result and any recovery decision into the rollback or recovery plan.
A retry should be a controlled continuation of a known request. When the result is still unknown, resolving that uncertainty is the next piece of work.
TechDex Presents…
Flashback to the ’90s
Get 2026 services at 1990s prices.
For a limited time, I’m rolling prices back on six focused small-business services. Choose one service for $800, or choose two for $1,200. Nothing is purchased here—I’ll review your request and confirm the scope with you first.
For related website work, explore this Rewind service:
The campaign form lets you choose one or two services and request a follow-up. It isn’t a checkout, and you won’t be billed when you submit it.