Idempotency Score Calculator
Score how idempotent an Ansible playbook is based on changed-task ratios across runs.
About Idempotency Score Calculator
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
Worked example
With the default values below, Idempotency Score Calculator returns Idempotency Score of 95.0%. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Total Tasks Runaccepts 1–100,000 tasks
- 120 tasks
- Changed Tasksaccepts 0–100,000 tasks
- 6 tasks
- Failed Tasksaccepts 0–100,000 tasks
- 0 tasks
Results
- Idempotency Score
- 95.0%
- Rating
- Highly idempotent
- Changed Task Rate
- 5.0%
- Failed Task Rate
- 0.0%
Step by step
- 1Unchanged tasks= 114 tasks
- 2Idempotency score: unchanged / total × 100= 95.0%
- 3Rating= Highly idempotent
Assumptions and limits
- The result is derived only from the 3 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 1 decimal place, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
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.