Anti-pattern: ignore_errors as a green-build button · Ansible

ignore_errors: true has a legitimate use and almost nobody reaches for it for that reason. It gets added because a task failed, the run stopped, somebody was in a hurry, and the keyword made the problem go away.

Then it gets added again. And the pipeline goes green, and stays green, and the estate underneath it stops being observable.

What it looks like in a repository

Service impact possiblethe anti-pattern - accumulated, not designed— SERVICE-IMPACT: these tasks change hosts and restart services. Every failure is discarded, so the run reports success regardless of outcome.

- name: Stop the application
ansible.builtin.systemd_service:
  name: app
  state: stopped
ignore_errors: true

- name: Deploy the new artefact
ansible.builtin.unarchive:
  src: 'https://artifacts.example.com/app-{{ app_version }}.tar.gz'
  dest: /srv/app
  remote_src: true
ignore_errors: true

- name: Run the database migration
ansible.builtin.command:
  cmd: /srv/app/bin/migrate
ignore_errors: true

- name: Start the application
ansible.builtin.systemd_service:
  name: app
  state: started
ignore_errors: true

Read the sequence. The artefact fails to download; the migration runs against the old code; the start succeeds because the old version is still installed. The run is green, the deployment did not happen, and the database has been migrated for a version that is not deployed.

Each ignore_errors was added for a defensible local reason. The first one, most likely, because stopping an already-stopped service failed once.

The recap, and the exit code

Read-only / Safea failing task, ignored— Real output from ansible-core 2.21.3. The task failed. The recap shows failed=0, and the process exited 0 - which is what a CI pipeline reads.

$ ansible-playbook -i inventory/hosts.yml deploy.yml; echo exit=$?

TASK [Deploy the application] **************************************************
fatal: [localhost]: FAILED! => {"changed": false, "msg": "artefact checksum mismatch"}
...ignoring

TASK [Report success] **********************************************************
ok: [localhost] => {
  "msg": "deployment complete"
}

PLAY RECAP *********************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1

exit=0

Two details worth having in mind at 03:00.

failed=0 and ignored=1. The recap does record it, in the last column, which almost nobody reads. Anything summarising runs by failed, or by exit code, sees a clean run.

Exit code 0. This is what CI reads, what a wrapper script reads, and what the monitoring check that watches for failed runs reads. The deployment failed and every automated observer was told it succeeded.

The cousin: `ignore_unreachable`

This one is worse, and its output is the most alarming in this part.

Read-only / Safea play with ignore_unreachable at play level— READ-ONLY as written: ping only connects and returns. The keyword's effect is what matters, not the module.

- name: Restart the fleet
hosts: web01.example.com,web02.example.com
gather_facts: false
ignore_unreachable: true
tasks:
  - name: Restart the application
    ansible.builtin.ping:

Read-only / Safetwo hosts that were never contacted— Real output from ansible-core 2.21.3 against hosts in 192.0.2.0/24, which is unreachable by design. Read the recap carefully: ok=1, unreachable=0, and exit code 0.

$ ansible-playbook -i inventory/hosts.yml unreach.yml -T 3; echo exit=$?

TASK [Restart the application] *************************************************
fatal: [web02.example.com]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 192.0.2.10 port 22: Connection timed out", "unreachable": true}
...ignoring
fatal: [web01.example.com]: UNREACHABLE! => {"changed": false, "msg": "Failed to connect to the host via ssh: ssh: connect to host 192.0.2.10 port 22: Connection timed out", "unreachable": true}
...ignoring

PLAY RECAP *********************************************************************
web01.example.com          : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1
web02.example.com          : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=1

exit=0

The three honest replacements

1. `failed_when` — be precise about what failure means

Most ignore_errors are really “this exit code is not a failure for my purposes”. Say that instead.

Configuration changea non-zero exit that is not an error— CONFIGURATION: the command runs. Only the specified condition marks the task failed, so genuine failures still stop the run.

- name: Check whether the ruleset would load
ansible.builtin.command:
  cmd: /usr/sbin/nft -c -f /etc/nftables.conf
register: nft_check
changed_when: false
failed_when: nft_check.rc not in [0, 1]

The difference is total: ignore_errors discards every failure including the ones you have not thought of, while failed_when names the acceptable outcomes and leaves everything else fatal.

For the “stop an already-stopped service” case that starts most of these, the answer is usually neither keyword — a module with proper state semantics does not fail when the desired state already holds.

2. `block`/`rescue` — compensate, then decide

Service impact possiblea failure that is handled rather than hidden— SERVICE-IMPACT: deploys and restarts. On failure the rescue restores the previous artefact and then fails deliberately, so the run reports what happened.

- name: Deploy with a compensating action
block:
  - name: Deploy the new artefact
    ansible.builtin.unarchive:
      src: 'https://artifacts.example.com/app-{{ app_version }}.tar.gz'
      dest: /srv/app
      remote_src: true

  - name: Start the application
    ansible.builtin.systemd_service:
      name: app
      state: started
rescue:
  - name: Restore the previous artefact
    ansible.builtin.command:
      cmd: /srv/app/bin/rollback-to-previous
    changed_when: true

  - name: Fail the run deliberately, having compensated
    ansible.builtin.fail:
      msg: >-
        Deploy of {{ app_version }} failed on {{ inventory_hostname }};
        previous version restored. Run not marked successful.

The final fail is the part that matters and the part usually omitted. A rescue block that ends without failing marks the task as rescued and the play continues — which is correct when the compensation genuinely resolved the situation, and a quieter version of this anti-pattern when it did not.

3. Let it fail

Often the right answer. If the task failing means the change did not happen, the run should stop and the operator should know. Part XXIII’s argument in one line: a run that stops halfway is recoverable; a run that reports success having done half the work is not, because nobody knows to recover it.

Finding them

Read-only / Safeaudit the repository— READ-ONLY: greps only. Rank the results by what the ignored task does, not by count.

cd /srv/ansible

grep -rn 'ignore_errors:\s*\(true\|yes\|True\)'    --include='*.yml' --include='*.yaml' .

grep -rn 'ignore_unreachable:\s*\(true\|yes\|True\)'    --include='*.yml' --include='*.yaml' .

# Recaps from previous runs, if you log them.
grep -h 'ignored=[1-9]' /var/log/ansible/*.log | tail -20

Rank by what the ignored task does. An ignored service restart or migration is a different order of problem from an ignored optional file deletion.
For each one, ask what specific failure it was added to suppress. If nobody knows, that is the finding.
Replace with failed_when where the answer is "this exit code is fine", which is most of them.
Replace with block/rescue where a compensating action exists - and check the rescue ends in a deliberate fail unless it genuinely resolved the problem.
Delete the rest and let the tasks fail. Then fix what fails, which is the work that was deferred when the keyword was added.
Add a CI check that fails on new ignore_errors outside an allowlist, so the count cannot silently grow again.

Under the hood

What exactly does ignore_errors change, and what does it leave alone?

It affects the play’s control flow and the recap, and nothing else. The task still runs, still fails, and its result is still registered — so a registered variable from an ignored task carries failed: true and can be tested afterwards. That is the one legitimate pattern that genuinely needs the keyword: run something that may fail, capture the result, and decide in a later task.

What it does not do is remove the failure from the host’s own state. If the task was half-applied, the host is in whatever state that left it, and the play carries on running subsequent tasks against it. This is the mechanism behind the deployment sequence at the top of this lesson: each ignored failure hands a broken host to the next task, which assumes the previous one succeeded.

ignore_unreachable is a different mechanism with a similar shape. An unreachable host is normally removed from the play entirely — Ansible stops attempting tasks against a host it cannot contact, which is why unreachable is a separate recap column from failed. With ignore_unreachable: true, the host stays in the play and subsequent tasks are attempted against it. Each of those either fails to connect again or, for controller-side actions such as debug, set_fact and assert, appears to succeed — which is where the ok=1 in the recap comes from.

That last detail is worth keeping. A play whose tasks are controller-side can report a full column of ok for a host that has been switched off for a week, and the validation notes for this course established exactly that behaviour. Combined with ignore_unreachable, it is possible to build a play that cheerfully reports success against an entire fleet that no longer exists.

The exit code follows the same logic. ansible-playbook exits 2 on task failure and 4 when any host is unreachable, with unreachable taking precedence. Both keywords remove the condition before the exit code is computed, so the process exits 0 — which is why a CI pipeline is the last place that will tell you about this.

What happens if removing ignore_errors makes the pipeline red every night?

Then the pipeline was already red every night and you have just made it visible. That is progress, and it will not feel like it for about a week.

The reflex is to put the keyword back. The alternative is a short triage.

Categorise each failure once. Real failure that needs fixing; acceptable outcome that needs a failed_when; environmental flake that needs until/retries; or a task that should not be running on that host at all and needs a when:. Most of these resolve into the last three, which are cheap.

Fix the cheap ones immediately so the noise drops fast enough that people do not give up. The pipeline going from forty failures to three in an afternoon is what buys the patience for the remaining three.

Split the pipeline if the remainder is large. A gating job containing only what must pass, plus a reporting job for the rest, is better than one job everybody ignores. An alarm that fires every night is not an alarm — it is background noise, and it trains people to ignore the one night it means something.

Timebox the remainder with owners. Anything not fixed in two weeks gets either a real fix, a documented and dated exception, or a decision that the task is not needed. All three are acceptable; leaving it undecided is how the keyword comes back.

The uncomfortable framing that tends to settle the argument: the failures were happening the whole time. The only thing that changed is whether anyone finds out before an incident does.

Knowledge check

Why this matters

Automation earns its place by being trusted. A playbook run that succeeds is supposed to mean the estate is in the state the repository describes, and everything downstream — the dashboard, the change record, the drift report, the on-call engineer’s first assumption — is built on that meaning.

ignore_errors breaks it silently. Not by producing a wrong answer, but by producing the right-looking answer regardless of what happened, which is strictly worse: a failure that stops the run is information, and a failure converted into a green tick is anti-information. It actively misleads the next person to look.

ignore_unreachable goes further still. It reports on hosts about which nothing at all is known, which means a fleet that has been switched off for a week can produce a full column of ok.

The keywords are not the problem. Both have narrow legitimate uses, and Part XXIII teaches them. The anti-pattern is the reflex — the run went red, the keyword made it green, and nobody asked what the red was telling us. That reflex is how a pipeline ends up passing over a broken fleet, and how a team ends up finding out from a customer.