Monitoring Ansible Automation with Vigilmon: Heartbeat Checks, SSH Bastion TCP Monitoring & SSL Alerts

Ansible runs your nightly compliance checks, patch management cycles, and configuration drift remediation — silently, in the background, often unattended. When a scheduled playbook run fails to start, the automation stops without any visible error: systems drift from their desired state, security patches aren't applied, and no one knows until the next audit or incident. Vigilmon gives you external visibility into Ansible automation through heartbeat monitors that detect missed runs, TCP port checks for the SSH bastions Ansible relies on, and SSL alerts for Ansible Automation Platform deployments — so you know the moment your automation stops working.

What You'll Build

• Heartbeat monitors for recurring Ansible playbook runs (nightly patching, compliance checks, config drift remediation)
• An HTTP monitor for AWX or Semaphore API health (if you use a control plane)
• A TCP port check for SSH bastion hosts that Ansible connects through
• SSL certificate monitoring for Ansible Automation Platform or AWX web UI

Prerequisites

• Ansible installed and running scheduled playbooks (cron, AWX/Semaphore, or systemd timers)
• Optionally: AWX or Ansible Semaphore for a web-based control plane
• SSH bastion host(s) Ansible uses to reach managed nodes
• A free account at vigilmon.online

Step 1: Understand Ansible's Monitoring Surface

Ansible itself is a push-based automation tool with no persistent process — playbooks run and exit. This makes traditional HTTP uptime monitoring insufficient. The key monitoring surfaces are:

# Verify a playbook runs successfully (exit code 0 means success)
ansible-playbook -i inventory/production site.yml --check
echo "Exit code: $?"

# Verify SSH connectivity to bastion
ssh -o ConnectTimeout=5 -o BatchMode=yes bastion.example.com echo ok

# Check AWX API health (if using AWX)
curl -s https://awx.example.com/api/v2/ping/ | python3 -m json.tool

The most impactful Vigilmon monitor for Ansible is the heartbeat: your playbook sends a ping to Vigilmon on successful completion, and Vigilmon alerts if the ping stops arriving — meaning the scheduled run failed or never started.

Step 2: Add Heartbeat Monitoring for Scheduled Playbook Runs

Heartbeat monitoring is Vigilmon's most powerful feature for Ansible. Your playbook sends a request to a Vigilmon heartbeat URL at the end of each successful run; Vigilmon alerts if the expected ping doesn't arrive within the configured window.

Create a Heartbeat Monitor

1. Log in to Vigilmon → Add Monitor → Heartbeat.
2. Label: Ansible nightly patch run.
3. Expected interval: Match your cron schedule — for nightly runs, set 24 hours (1440 minutes).
4. Grace period: 30 minutes (allows for playbook runs that take longer than usual).
5. Click Save and copy the heartbeat URL (e.g., https://vigilmon.online/heartbeat/abc123).

Instrument Your Playbook

Add a final task to your playbook that pings Vigilmon on success:

# At the end of your playbook, after all tasks:
- name: Ping Vigilmon heartbeat on successful completion
  uri:
    url: "https://vigilmon.online/heartbeat/abc123"
    method: GET
    status_code: 200
  delegate_to: localhost
  run_once: true
  ignore_errors: false

For cron-triggered playbooks, wrap the ping in your cron job:

# /etc/cron.d/ansible-nightly
0 2 * * * ansible /usr/bin/ansible-playbook /opt/ansible/site.yml -i /opt/ansible/inventory/prod && curl -fsS https://vigilmon.online/heartbeat/abc123 > /dev/null

The && operator ensures the heartbeat only fires on successful completion (exit code 0). If the playbook fails, the heartbeat is not sent, and Vigilmon alerts after the grace period.

Separate Heartbeats per Playbook Role

For critical automation, create one heartbeat monitor per major playbook:

| Playbook | Vigilmon Label | Interval | |---|---|---| | Nightly OS patch management | Ansible patch run | 24h | | Hourly config drift remediation | Ansible config drift | 60 min | | Weekly compliance scan | Ansible compliance | 7 days | | Scheduled user provisioning | Ansible user sync | 24h |

Step 3: Monitor AWX or Ansible Semaphore API Health

If you use AWX (the upstream for Red Hat Ansible Automation Platform) or Ansible Semaphore as a web-based Ansible control plane, monitor their API availability:

AWX Health Check

AWX exposes a ping endpoint that confirms the API and database connectivity:

curl https://awx.example.com/api/v2/ping/
# Returns: {"ha": false, "version": "24.x.x", "active_node": "...", "install_uuid": "..."}

1. Add Monitor → HTTP.
2. URL: https://awx.example.com/api/v2/ping/.
3. Check interval: 2 minutes.
4. Response timeout: 15 seconds.
5. Expected status: 200.
6. Keyword: version (present in all healthy AWX ping responses).
7. Label: AWX API ping.
8. Click Save.

Ansible Semaphore Health Check

Semaphore provides a health endpoint:

curl https://semaphore.example.com/api/ping
# Returns: "pong"

1. Add Monitor → HTTP.
2. URL: https://semaphore.example.com/api/ping.
3. Check interval: 2 minutes.
4. Expected status: 200.
5. Keyword: pong.
6. Label: Semaphore API health.
7. Click Save.

Ansible Automation Platform (AAP): AAP exposes a /api/v2/ping/ endpoint similar to AWX. Monitor https://aap.example.com/api/v2/ping/ with keyword version.

Step 4: Create a TCP Monitor for SSH Bastion Hosts

Ansible connects to managed nodes over SSH. In most production environments, this goes through an SSH bastion (jump host). If the bastion is unreachable, every Ansible playbook targeting production nodes fails immediately:

# Verify SSH bastion is reachable
nc -zv bastion.example.com 22
# or
ssh -o ConnectTimeout=5 -o BatchMode=yes bastion.example.com echo ok

1. Add Monitor → TCP.
2. Host: bastion.example.com.
3. Port: 22 (SSH) — or your custom SSH port.
4. Check interval: 1 minute.
5. Response timeout: 10 seconds.
6. Label: Ansible SSH bastion.
7. Click Save.

If you have multiple bastion hosts (e.g., per-region or per-environment), create a TCP monitor for each:

| Bastion | Port | Label | |---|---|---| | bastion-us.example.com | 22 | Ansible bastion US | | bastion-eu.example.com | 22 | Ansible bastion EU | | bastion-prod.example.com | 22 | Ansible bastion prod |

When a TCP monitor fires but AWX/Semaphore HTTP monitors are green, the control plane is healthy but Ansible can't reach managed nodes — a targeted network incident rather than a full outage.

Step 5: Monitor SSL Certificates for Ansible Automation Platform

Ansible Automation Platform and AWX serve their web UI and API over HTTPS. An expired certificate causes:

• AWX API calls from CI/CD pipelines to fail with TLS errors
• Web UI access to show certificate warnings
• Ansible collections downloaded from Automation Hub to fail if Hub's certificate expires

1. Add Monitor → SSL Certificate.
2. Domain: awx.example.com (or aap.example.com, semaphore.example.com).
3. Alert when expiry is within: 30 days.
4. Alert again: 14 days, 7 days, 3 days, 1 day.
5. Click Save.

# Verify certificate expiry manually
openssl s_client -connect awx.example.com:443 2>/dev/null | openssl x509 -noout -dates

Self-signed certificates: AWX defaults to a self-signed certificate. If you've replaced it with a Let's Encrypt or CA-signed certificate, Vigilmon will monitor it. Self-signed certificates can't be verified by Vigilmon's external checks — you'll need to replace them with a trusted certificate first.

Step 6: Monitor the AWX Web UI Login Page

The AWX web UI is the interface your team uses to launch jobs, view schedules, and manage inventories. Monitor it separately from the API ping:

1. Add Monitor → HTTP.
2. URL: https://awx.example.com.
3. Check interval: 5 minutes.
4. Expected status: 200.
5. Keyword: AWX (appears in the page title).
6. Label: AWX web UI.
7. Click Save.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, set up alert routing:

| Monitor | Trigger | Action | |---|---|---| | Heartbeat (nightly patch) | No ping within window | Check cron logs; verify Ansible inventory is reachable | | Heartbeat (compliance) | No ping within window | Compliance scan missed; manual run or investigate failure | | AWX API ping | Non-200 or keyword missing | systemctl status awx; check AWX logs in /var/log/tower/ | | SSH bastion TCP | Connection refused or timeout | Check bastion host health; verify security group/firewall rules | | SSL certificate | < 30 days to expiry | Renew via Certbot or reissue through your CA |

Alert sensitivity for heartbeats: Trigger immediately when a heartbeat is missed — a missed run is an outage, not a flap.

Common Ansible Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Cron job not running (misscheduled or disabled) | Heartbeat alert after grace period | | Playbook fails mid-run (no exit 0) | Heartbeat never sent; alert fires | | SSH bastion unreachable | TCP monitor fires; all managed-node plays fail | | AWX worker process crash | API ping fails; job schedules stop executing | | Managed node SSH key rotation breaks connectivity | Heartbeat fires (playbook errors, no success ping) | | SSL certificate expires on AWX | API calls from pipelines fail with TLS errors | | Ansible control node disk full | Playbooks fail; heartbeat not sent | | Inventory source unreachable (dynamic inventory) | Playbooks error; heartbeat alert | | AWX database connection failure | API ping fails; no jobs can be launched |

Ansible automation runs silently — when it's working, you don't see it; when it stops, you often don't see that either until you audit the results. Vigilmon's heartbeat monitoring closes this gap: every scheduled playbook run is expected to check in, and you're alerted the moment that check-in stops. Combined with SSH bastion TCP monitoring and AWX API health checks, you have complete visibility into whether your automation infrastructure is functional — not just whether the control plane is running, but whether it's actually doing the work.

Start monitoring Ansible in under 5 minutes — register free at vigilmon.online.