Reading changed vs ok in Output
Interpret what a run actually did.
Reading changed vs ok in Output is a free Ansible Academy lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Ansible Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Every Task Reports a Status
After each task, Ansible prints a status per host. The two you will see most are ok and changed, and they tell different stories.
ok Means Already Correct
A status of ok means the host already matched the desired state. The task ran its check but made no change at all.
ok: [web1]changed Means It Acted
A status of changed means the host did not match, so the module modified something to converge it to your declared state.
changed: [web1]Yellow vs Green
By default Ansible colors changed output yellow and ok output green. A wall of green on a second run is exactly what you want.
The PLAY RECAP Sums It Up
At the end, the PLAY RECAP tallies counts per host: ok, changed, unreachable, and failed. It is your one-line health check.
web1 : ok=4 changed=1 unreachable=0 failed=0Second Run Should Be All ok
Run an idempotent playbook twice and the second recap should show changed=0. Any change on a repeat run is worth investigating.
web1 : ok=4 changed=0 unreachable=0 failed=0changed Is Not an Error
A changed status is success, not a problem. It simply records that the host needed work and the task did it correctly.
skipping Means a Condition Failed
You may also see skipping, which means a when condition was false so the task was not run on that host.
skipping: [db1]failed and unreachable
A failed status means the task errored; unreachable means Ansible could not even connect over SSH. Both stop that host's play.
Use changed to Verify Idempotency
The changed count is your idempotency meter. A repeated run that keeps reporting changes means a task is not truly idempotent.
See More Detail with -v
Add -v (or -vv) to ansible-playbook for verbose output showing exactly what each task changed and why.
ansible-playbook site.yml -vQuick Check
You run the same playbook a second time and the recap shows ok=5 changed=0.
Recap
Read ok as 'already correct' and changed as 'just fixed'. The PLAY RECAP and a changed=0 repeat run prove your play is idempotent. ✅
Frequently asked questions
Is the “Reading changed vs ok in Output” lesson free?
Yes — the full text of “Reading changed vs ok in Output” is free to read here on the web, and the Ansible Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Ansible Academy course, upgrade to CoddyKit PRO.
What will I learn in “Reading changed vs ok in Output”?
Interpret what a run actually did. You practise Ansible Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Ansible Academy?
No prior experience is required. Ansible Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Reading changed vs ok in Output” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Ansible Academy lesson?
Yes. Every Ansible Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Desired State, Not Step-by-Step Scripts
- Reading changed vs ok in Output
- Why command Breaks Idempotency
- Check Mode: Dry-Run with --check