Idempotency in automation: why every operation should be safe to run twice

Picture this: your automation processes 500 user accounts overnight. Somewhere along the way the network drops and the run stops at number 312. What happens when you restart it?

If your automation is not idempotent, users 1-312 might get duplicate accounts or have their data updated twice. The same invoice or order confirmation gets sent twice. Folders or records get deleted a second time.

Idempotency means that an operation can be run multiple times without the outcome changing. Whether you run the script once or ten times, the result is the same.

Why this comes up in production

Because things break in production. Networks drop. Servers restart mid-run. Someone runs the script again by mistake. Task Scheduler triggers a run that is already in progress.

All of these happen eventually. If the automation cannot handle them, it becomes a liability.

How to implement idempotency in practice

Check before you act

Instead of acting directly, check first whether the action has already been taken.

Example in PowerShell, creating a user account:

$user = Get-ADUser -Filter {SamAccountName -eq "mvirtanen"} -ErrorAction SilentlyContinue

if (-not $user) {
    New-ADUser -Name "Matti Virtanen" -SamAccountName "mvirtanen" ...
    Write-Output "User created: mvirtanen"
} else {
    Write-Output "User already exists, skipping: mvirtanen"
}

The same logic applies to files, folders, configuration, and API calls.

Use upsert operations

Many databases and APIs support upsert operations: update if the record exists, create if it does not. This is idempotency built in.

Track what has been done

A checkpoint model means recording how far you got so a rerun can continue from there rather than starting from the beginning. At its simplest this is a text file containing the last successfully processed ID or line number.

A design decision, not an afterthought

Idempotency is not something you add later. It is a design decision that needs to be made at the start.

Adding it after the fact is significantly more work, because it affects the entire structure of the automation logic. And in most cases it only gets added after something goes wrong in production.

Build idempotently from the start. You will save considerable effort later.

Want to check whether your automations are safe to re-run? Get in touch.