Idempotency Score Calculator
Score how idempotent an Ansible playbook is based on the ratio of unchanged tasks across a steady-state run.
Inputs
Total task executions across all hosts in a steady-state (second) run.
Task executions that reported 'changed' on a run against infrastructure already in the desired state.
Task executions that failed outright — these count against idempotency too.
Idempotency Score
95.0%
Rating
Highly idempotent
Changed Task Rate
5.0%
Failed Task Rate
0.0%
Step by step
Unchanged tasks
120 − 6 − 0
= 114 tasks
Idempotency score: unchanged / total × 100
114 / 120 × 100
= 95.0%
Rating
based on score thresholds
= Highly idempotent
How it works
A perfectly idempotent playbook run against infrastructure already in its desired state should report zero changes — running it again shouldn't 'do' anything. Idempotency score = unchanged_tasks / total_tasks × 100, measured on a run where you expect no real changes (a 'steady-state' or second consecutive run). A 100% score means the playbook fully converges; lower scores point to tasks using `shell`/`command` without proper `changed_when`/`creates` guards, or genuinely non-idempotent logic.
Formula
idempotency_score = (unchanged_tasks / total_tasks) × 100
- unchanged_tasks
- Tasks reporting 'ok' (no change) on a second run
- total_tasks
- Total tasks executed in the playbook
Frequently Asked Questions
How do I measure this in practice?
Run the playbook twice in a row against the same infrastructure. The second run's changed-task count (ideally zero) is what you plug into this calculator — a well-behaved playbook should report 'changed=0' on that second run.
What commonly breaks idempotency?
Raw `shell`/`command` tasks without `changed_when` (they report 'changed' every time by default), tasks that always overwrite a timestamped file, and templates whose Jinja2 output isn't stable across runs (e.g. embedding the current date).
Is 100% idempotency always achievable?
Nearly always for configuration management tasks, but some legitimately stateful operations (rotating a secret, appending to a log) are inherently non-idempotent by design — flag those explicitly rather than treating a nonzero score as a bug.
Does a failed task count against idempotency?
Yes in this model — a failure means the playbook didn't successfully converge to the desired state, which is a distinct problem from 'changed' but still means the run wasn't a clean no-op success.