What does "safe to re-run" mean?

What it is, in plain words

Press a lift button once and a lift comes. Press it five more times and still only one lift comes. The button is safe to press again.

A vending machine that takes your coin each time you press is not. Press twice, pay twice.

Developers call the lift-button kind idempotent. For an automation, it means: if the same run happens twice, on the same input, the second run does nothing new. No second email, no second post, no second invoice.

Automations repeat themselves more often than buyers expect:

• Retries. A step fails, or seems to fail, and the automation tries again.
• Double triggers. The sending app delivers the same event twice, which webhooks can do when a delivery is retried.
• People. Someone presses Run again “to be sure”, or re-imports yesterday’s file.
• Catch-up runs. A job that missed its time runs when the machine wakes up, and the next scheduled run is right behind it.

An automation that is safe to re-run treats all four the same way: it checks what is already done, and only does what is not.

A concrete example from my own publishing job

I run a scheduled job that publishes posts to a social account through the platform’s API. In August 2026 it taught me why “safe to re-run” has to cover errors too.

Over two days, the API answered several publish requests with errors: a request-limit error, and on one post a generic “fatal” error as well. My job treated each error as a failure and retried. Five posts were recorded as failed. When I looked at the account, all five had been published.

What the job saw	What had actually happened
Error on publish	The post was live
“Failed”, so retry	Retrying a post that was already out
Ledger not updated	The duplicate check no longer knew those posts existed
Failure alert sent	The alert worked; it faithfully reported a wrong judgement

The job was now retrying work that was already done, and the record that should have stopped a second copy no longer listed those posts. The API I publish through has no delete call, so any duplicate would have stayed up until someone removed it by hand.

The fix was a rule, not a longer retry: before treating an error as a failure, check whether the thing actually happened. The job now looks up recent posts on the account. If the post is there, it records a success and stops. Only if it is not there does it count as a failure.

Two smaller details mattered:

• What counts as “the same”. I publish one topic in two formats. Matching on the first line of the caption alone would have mistaken one format for the other, so the check also compares the post type.
• Where the record lives. For automatic first comments, the API would not show my own comments back to me, so looking them up could not prevent a repeat. The job writes the comment’s ID to its own ledger instead, and skips any post that already has one.

Why it matters when you hire someone

A demo almost never shows this. Each step runs once, on clean data, with a good connection. Duplicates appear later, on the night the network drops for a minute.

Three things go wrong when the buyer does not ask:

1. Retries without a record. The freelancer adds retries to make the automation reliable, which is right, but not the check that stops a retry from repeating a finished action. Reliability becomes duplication.

2. “Error” is trusted as “did not happen”. Many services can complete an action and still return an error, for example when a response times out on the way back. An automation that never checks the result will repeat it.

3. Nobody owns the ledger. Being safe to re-run depends on a record of what was done: a sheet, a database table, a file. If it lives in the freelancer’s account, or is cleared when someone resets the job, the protection goes with it.

This is why the acceptance checklist for unattended automations includes a duplicate-run test, and why the workflow automation acceptance lines ask you to run a finished job again by hand.

What to ask the freelancer

A good answer names the record, says what is checked before each action, and offers to prove it: run a finished job again in front of you and show that nothing new was sent.