What are handlers in Ansible and when do they run?
Learn how Ansible handlers work — triggered by notify only on change, run once at the end of a play, and controlled with meta: flush_handlers.
Expected Interview Answer
Handlers are special Ansible tasks that run only when notified by another task that reports a 'changed' state, and by default they execute once, at the very end of the play, after all regular tasks finish.
A task triggers a handler with the notify keyword referencing the handler's name; if the task makes no change, the notification is not sent and the handler stays idle. Even if many tasks notify the same handler, it runs a single time to avoid redundant restarts. Handlers are commonly used to restart or reload services only when configuration actually changed, and you can force them to run earlier with the meta: flush_handlers task.
- Restart services only when something actually changed
- Deduplicate work — one run no matter how many notifies
- Keep playbooks idempotent and efficient
- Cleanly separate 'make change' from 'react to change'
- Control timing with meta: flush_handlers when needed
AI Mentor Explanation
Think of the twelfth man who only comes on when a fielder is genuinely injured. Bowlers and batters signal 'we need a sub', but he doesn't run out for every ball — he waits until the over is complete, and even if three players call for him, he responds just once at the break rather than repeatedly disrupting play.
Step-by-Step Explanation
Step 1
Define the handler
Under the handlers: section (or a handler file), create a task with a unique name such as 'restart nginx' that performs the reaction, e.g. an ansible.builtin.service restart.
Step 2
Notify from a task
In a regular task, add notify: 'restart nginx'. The notification is queued only if that task returns a 'changed' result.
Step 3
Finish the play's tasks
Ansible runs all remaining normal tasks first; queued handlers do not fire mid-play by default.
Step 4
Run notified handlers once
At the end of the play, each notified handler runs a single time in the order handlers are defined — not the order they were notified.
Step 5
Flush early if required
Insert a - meta: flush_handlers task to force pending handlers to run immediately, useful before a dependent later task.
What Interviewer Expects
- Handlers run only when notified by a changed task
- They execute once at the end of the play by default
- notify keyword links a task to a handler by name
- Multiple notifies to one handler still run it once
- Awareness of meta: flush_handlers to control timing
- Handler run order follows definition order, not notify order
Common Mistakes
- Thinking handlers run immediately after the notifying task
- Assuming a handler runs even when the task made no change
- Expecting a handler to run per notify instead of once
- Believing handlers run in notification order rather than definition order
- Forgetting handler names must match the notify string exactly
Best Answer (HR Friendly)
“Handlers are helper steps that only kick in when something has genuinely changed — like restarting a web server only after its config file was edited. Ansible waits until the main work is done, then runs each needed handler just once so nothing is restarted unnecessarily.”
Code Example
- hosts: web
become: true
tasks:
- name: Deploy nginx config
ansible.builtin.template:
src: nginx.conf.j2
dest: /etc/nginx/nginx.conf
notify: restart nginx
handlers:
- name: restart nginx
ansible.builtin.service:
name: nginx
state: restarted - name: Apply config now
ansible.builtin.template:
src: app.conf.j2
dest: /etc/app/app.conf
notify: restart app
- name: Flush pending handlers before the smoke test
ansible.builtin.meta: flush_handlers
- name: Smoke test the restarted app
ansible.builtin.uri:
url: http://localhost:8080/healthFollow-up Questions
- What does meta: flush_handlers do and when would you use it?
- If two tasks notify the same handler, how many times does it run?
- Why might a handler not run even though you expected a change?
- In what order do multiple notified handlers execute?
- How can you notify multiple handlers from a single task?
- How do handlers behave when a play fails partway through?
MCQ Practice
1. When does a notified handler run by default?
By default handlers are queued and run a single time at the end of the play, after all regular tasks have completed.
2. A handler is notified by five different tasks in one play. How many times does it run?
No matter how many tasks notify it, a handler runs only once per play to avoid redundant actions like repeated restarts.
3. Which construct forces pending handlers to run immediately?
The 'meta: flush_handlers' task triggers all currently queued handlers to execute at that point in the play.
Flash Cards
What triggers a handler? — A task using notify: that returns a 'changed' status — an unchanged task sends no notification.
When do handlers run by default? — Once, at the end of the play, after every regular task has completed.
How many times does a handler run if notified repeatedly? — Exactly once per play, regardless of how many tasks notify it.
What order do multiple handlers run in? — In the order they are defined, not the order in which they were notified.
How do you run handlers mid-play? — Insert a '- meta: flush_handlers' task to flush queued handlers immediately.