How do we know whether a step is safe to repeat?

The vendor's own documentation usually says, because it is a property they either designed for or did not. Look for whether the operation accepts a key supplied by the caller. Where nothing is offered and the step creates something, assume a repeat creates a second one and build the check yourself.

Does this only matter for payments?

It matters wherever repeating a step would be visible to somebody. Duplicate invoices are the memorable case, and duplicate tickets, duplicate messages to a customer and duplicate records in a system of record all cause real work. Reads and reports are the genuinely safe end of it.

Is this something we configure, or something we ask about?

Both, in different places. How often your automation tries again is a setting on your side and you control it. Whether trying again is safe belongs to whatever you are calling, so it is a question for the vendor or their documentation rather than a switch you can turn on yourself.

Glossary

Idempotency

The property that repeating an operation changes nothing beyond what the first attempt already did, which is what makes trying a failed step again safe.

In plain terms

Pressing the button twice gives you what pressing it once would have given you. A lift call button behaves this way and a vending machine does not, which is why nobody worries about jabbing the first and everyone is careful with the second. In software the same distinction decides whether a failed step can simply be tried again.

Why it matters

Because automation tries again, and it does so at exactly the moment nobody is watching. A step that times out has not necessarily failed: the request may have arrived, been acted on, and had its confirmation lost on the way back. The automation cannot tell those apart, so it repeats itself, and whether that is harmless or produces a second invoice depends on the property of the thing being called rather than on anything the automation can decide for itself.

How it works

The uncertainty is in the reply, not the request. When a call fails without an answer, the caller knows only that no confirmation arrived, and the two possibilities behind that are that the request never landed, or that it landed and the response was lost. Nothing available to the caller distinguishes them, which is why the question is never whether to try again but whether trying again is safe.

Reading is naturally safe and writing usually is not. Asking for a record twice costs nothing and returns the same record; creating a record twice creates two of them. The distinction is not about the tool being careful, it is about the operation itself, and it is why the same automation can be perfectly safe on one step and dangerous on the next.

The usual remedy is a key supplied by the caller. The caller attaches a value it generates once and reuses on every attempt, and the receiving end records it and recognises a repeat, returning the original outcome instead of acting a second time. The work of deciding what counts as a duplicate has moved to the side that can actually see both attempts.

The guarantee is bounded, and the bound is worth knowing. A receiving end that remembers those keys usually remembers them for a period rather than forever, and a repeat arriving after that window looks like a fresh request. That is rarely a problem for an automatic attempt seconds later, and it is a problem for a person rerunning yesterday's failed job by hand.

Where the property is absent, the compensating move is to make the operation ask before it acts. A step that searches for an existing match and creates only when there is none is not idempotent in the strict sense and behaves like it in practice. It is slower and it is more to maintain, and it is what people build when the receiving end offers no key.

What a timeout leaves you knowing

Setting the two columns beside each other is worth doing because the left one feels like more information than it is. A step that reported nothing has told you about the channel rather than about the work, and the natural reading of silence is that nothing happened. That reading is wrong about half the time in the cases that matter, since a request acted on and a confirmation lost produces exactly the same silence as a request that never arrived. Nothing the caller can inspect distinguishes them, and no amount of care in the automation changes that, because the missing information is on the other side of a connection that has already failed. What resolves it is the receiving end offering a way to recognise a repeat, at which point the right-hand column stops mattering: the caller can try again without needing to know which of the two happened. That is the whole reason the property is worth asking a vendor about rather than something to reason out from your own side.

Seen in the wild

An automation that creates a task from an inbound email, where a repeated step would produce the task twice.
Zapier
A workflow posting to a finance system, where the receiving end offers a key so a repeated call is recognised.
Make
A step that looks up a contact before creating one, because the destination provides no way to recognise a repeat.
n8n

Common misconceptions

People assume

A failed step means nothing happened.

In fact

It means no confirmation came back. The request may have arrived and been acted on, with only the reply lost, and the caller cannot tell the difference. Treating a timeout as proof of inaction is how the same thing gets created twice.

People assume

Turning off automatic attempts avoids the problem.

In fact

It replaces a duplicate with a silent gap. The step that genuinely failed now stays failed, and somebody has to notice it. Most people would rather have the automation try again and have a way of making that safe, which is what this property is for.

Questions

How do we know whether a step is safe to repeat?: The vendor's own documentation usually says, because it is a property they either designed for or did not. Look for whether the operation accepts a key supplied by the caller. Where nothing is offered and the step creates something, assume a repeat creates a second one and build the check yourself.
Does this only matter for payments?: It matters wherever repeating a step would be visible to somebody. Duplicate invoices are the memorable case, and duplicate tickets, duplicate messages to a customer and duplicate records in a system of record all cause real work. Reads and reports are the genuinely safe end of it.
Is this something we configure, or something we ask about?: Both, in different places. How often your automation tries again is a setting on your side and you control it. Whether trying again is safe belongs to whatever you are calling, so it is a question for the vendor or their documentation rather than a switch you can turn on yourself.

Key takeaways

A timeout does not tell you whether the work happened.
Reads are safe to repeat; anything that creates usually is not.
A caller-supplied key is the standard way to make a repeat recognisable.
Where the receiving end offers nothing, the workaround is to check before acting.