AnsibleByExample

Ansible Playbook Example: Automated Branch Network Health Check

Advanced
2024-01-014By Luca Berton

Lesson 1 of 15 in Foundations

Ansible Foundations to Production — full curriculum
  1. 1. Introduction to Ansible and Automation
  2. 2. Installing and Configuring Ansible
  3. 3. Running Ad-Hoc Commands
  4. 4. Writing Your First Playbook
  5. 5. Understanding and Using Modules
  6. 6. Variables and Facts
  7. 7. Conditionals and Loops
  8. 8. Handlers and Idempotency
  9. 9. Structuring Projects with Roles
  10. 10. Inventory Management
  11. 11. Using Ansible Vault for Secrets
  12. 12. Debugging and Troubleshooting
  13. 13. Real-World Automation Examples
  14. 14. Final Project: Deploy a Web Server
  15. 15. Bonus - What's Next with Ansible?
View path overview →

At Red Hat Tech Day Netherlands 2026 in Bunnik, Fred van Zwieten and Ismail Dhaoui demoed the new Automation Portal in AAP 2.7, a self-service template gallery where operators click "Start" without needing to know where a playbook lives or how to configure it. One of the branch-office templates shown was Branch - Network Health Check, which runs a general health check across an entire branch. Below is a runnable playbook that models what such a template executes behind that button.

Example Playbook

---
- name: "Branch - Network Health Check"
  hosts: branch_network
  gather_facts: false
  vars:
    health_check_timeout: 10
    max_cpu_threshold: 80
    max_memory_threshold: 85

  tasks:
    - name: Verify device reachability
      ansible.builtin.wait_for_connection:
        timeout: "{{ health_check_timeout }}"
      register: reachability

    - name: Gather network device facts
      ansible.netcommon.net_facts:
      register: net_info

    - name: Check CPU utilization
      ansible.netcommon.cli_command:
        command: show processes cpu | include CPU utilization
      register: cpu_output
      changed_when: false

    - name: Check interface status for errors
      ansible.netcommon.cli_command:
        command: show interfaces | include (errors|CRC|drops)
      register: interface_errors
      changed_when: false

    - name: Check uplink and WAN link status
      ansible.netcommon.cli_command:
        command: show ip interface brief
      register: uplink_status
      changed_when: false

    - name: Build health check summary
      ansible.builtin.set_fact:
        branch_health_summary:
          host: "{{ inventory_hostname }}"
          reachable: "{{ reachability is succeeded }}"
          cpu_report: "{{ cpu_output.stdout }}"
          interface_errors_found: "{{ interface_errors.stdout | length > 0 }}"
          uplink_report: "{{ uplink_status.stdout }}"

    - name: Report unhealthy branch device
      ansible.builtin.debug:
        msg: "WARNING: {{ inventory_hostname }} flagged interface errors or CPU pressure"
      when: branch_health_summary.interface_errors_found

    - name: Write health check report per host
      ansible.builtin.copy:
        content: "{{ branch_health_summary | to_nice_yaml }}"
        dest: "/tmp/branch_health_{{ inventory_hostname }}.yaml"
      delegate_to: localhost

What It Does

The play targets a branch_network inventory group covering everything at a site — switches, routers, access points, and firewalls grouped together. It first confirms reachability with wait_for_connection, then pulls facts and CPU, interface error, and uplink status via ansible.netcommon modules, which work across supported network platforms without needing a vendor-specific collection for basic CLI checks. Results are assembled into a per-host summary, flagged if problems are found, and written locally as a YAML report.

In the Automation Portal demo, this logic sits behind a job template with a survey (branch name or site ID) and a single "Start" button — the operator never touches an inventory file or credential. The template gallery pattern from AAP 2.7 exists precisely so that non-Ansible-experts (NOC staff, branch IT) can trigger this without knowing it's a playbook at all.

Notes / Gotchas

  • Replace ansible.netcommon.cli_command with vendor-specific modules (e.g., cisco.ios.ios_command, arista.eos.eos_command) if you need structured, parsed output rather than raw CLI text.
  • gather_facts: false is intentional — standard Ansible facts gathering doesn't apply to network OS devices; use ansible.netcommon.net_facts instead.
  • Set realistic health_check_timeout values for branch links with higher latency than campus networks; a WAN-connected branch may need more than the default wait_for_connection timeout.
  • The to_nice_yaml report-writing task delegates to localhost — without delegate_to, Ansible tries to write the file on the network device itself, which fails.
  • In a real Automation Portal template, wire the report output to a controller artifact or notification (Slack, email) rather than a local /tmp file, so branch staff see results without shell access.

A branch health check like this turns a multi-step manual troubleshooting routine into a one-click, consistent, auditable job — exactly the self-service pattern Red Hat showcased for AAP 2.7's Automation Portal.

References

All Tutorials