tutorial

Monitoring Rundeck with Vigilmon: Web UI, API Health, Job Executor Heartbeats & SSL Alerts

How to monitor Rundeck runbook automation with Vigilmon — login page availability, API health checks, job executor heartbeat monitoring, and SSL certificate alerts.

Rundeck is the runbook automation backbone for ops teams — scheduling and executing operational jobs across servers, handling deployments, database backups, compliance checks, and incident remediation without requiring engineers to have SSH access to every host. When Rundeck goes down, scheduled jobs stop running silently, on-call engineers lose their self-service runbook portal, and incident remediation workflows grind to a halt — often at exactly the wrong moment. Vigilmon gives you external visibility into Rundeck before your ops team notices: the login page, API health, database connectivity, and most importantly, whether Rundeck can actually execute jobs.

What You'll Build

  • A monitor on Rundeck's login page to catch application and database failures
  • A monitor on the Rundeck API health endpoint for metadata availability
  • A heartbeat monitor that verifies Rundeck can actually run scheduled jobs
  • SSL certificate monitoring for HTTPS Rundeck deployments
  • An alerting setup that distinguishes process failures from job scheduler stalls

Prerequisites

  • A running Rundeck instance (Community Edition or Runbook Automation) accessible via HTTP or HTTPS
  • A domain or IP pointing to Rundeck (e.g., https://rundeck.example.com or http://rundeck.example.com:4440)
  • A free account at vigilmon.online

Step 1: Verify Rundeck's Health Endpoints

Rundeck serves its web UI and API on port 4440 by default (HTTP). The login page is the most reliable external health signal:

# Standard Rundeck on default port
curl -I http://rundeck.example.com:4440/

# Behind a reverse proxy (nginx/Apache)
curl -I https://rundeck.example.com/user/login

A GET to / returns a 302 redirect to /user/login. The login page itself returns HTTP 200 when Rundeck's Java application server is running and the database connection is healthy — the login page renders CSRF tokens and session data from the database, so a 500 error instead of the login form indicates a database connectivity failure.

For API health, Rundeck exposes system metadata at /api/1/system/info:

# Returns JSON with version and server metadata (may require auth token in newer versions)
curl -H "X-Rundeck-Auth-Token: YOUR_API_TOKEN" \
  https://rundeck.example.com/api/1/system/info

Authentication note: Newer Rundeck versions (4.x+) require an API token or active session cookie for /api/1/system/info. For unauthenticated external health monitoring, the login page is more reliable — it confirms both the Java app server and the database are healthy.

Step 2: Create a Vigilmon HTTP Monitor for the Login Page

The login page check is your primary Rundeck health signal — it confirms the JVM is running, the Grails application loaded, and the database connection is working:

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://rundeck.example.com/user/login (or http://rundeck.example.com:4440/user/login).
  3. Check interval: 60 seconds.
  4. Response timeout: 15 seconds (Rundeck's Java/Grails app can be slow to respond under load).
  5. Expected status: 200.
  6. Keyword: Log In (appears in the login page title and form button).
  7. Click Save.

This monitor catches:

  • JVM crashes or out-of-memory kills
  • Database connectivity failures (the login page won't render without a working DB connection)
  • Grails application startup failures after upgrades or plugin changes
  • Misconfigured JDBC connections causing Rundeck to start but fail to serve pages

Alert sensitivity: Set alerts to trigger after 2 consecutive failures. Rundeck's JVM can pause briefly during garbage collection; two consecutive failures reliably indicate a real outage rather than a GC pause.

Step 3: Create a Vigilmon HTTP Monitor for the API Endpoint

The Rundeck REST API powers integrations, CI/CD pipeline triggers, and infrastructure automation scripts. Monitor the system info endpoint to catch API-layer failures:

  1. Add Monitor → HTTP.
  2. URL: https://rundeck.example.com/api/1/system/info.
  3. Check interval: 5 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200 (if using an API token) or 403 (if anonymous — a 403 from Rundeck means the API is up and requiring authentication as expected).
  6. Keyword: rundeck (appears in the JSON response {"system":{"rundeck":{...}}}).
  7. Click Save.

Using an API token: In Rundeck, go to User Menu → Profile → User API Tokens → Generate New Token. Add the token as an HTTP header in Vigilmon: X-Rundeck-Auth-Token: YOUR_TOKEN. This allows keyword monitoring of the full JSON response.

Unauthenticated setup: If you prefer not to manage API tokens in Vigilmon, configure expected status 403 — a 403 from the API endpoint confirms Rundeck is running and enforcing authentication. A 502, 503, or connection error means the API is genuinely down.

Step 4: Set Up Heartbeat Monitoring for the Job Executor

The most critical Rundeck health signal isn't the web UI — it's whether Rundeck can actually run jobs. The web UI can be green while the internal job scheduler is stalled. Set up a dedicated Rundeck job that POSTs to a Vigilmon heartbeat URL on a schedule:

In Vigilmon:

  1. Add Monitor → Heartbeat.
  2. Name: Rundeck job executor.
  3. Expected interval: 65 minutes (slightly more than the job schedule to allow for execution time).
  4. Grace period: 5 minutes.
  5. Copy the generated heartbeat URL (e.g., https://api.vigilmon.online/heartbeat/abc123).

In Rundeck, create a new job:

  1. Go to Jobs → Create Job.
  2. Job Name: Vigilmon Health Heartbeat.
  3. Group: monitoring (optional).
  4. Schedule: Every hour (0 * * * * in cron notation).
  5. Under Add a Step → Command, add: 
    curl -fsS https://api.vigilmon.online/heartbeat/abc123
  6. Notifications: Add a failure notification (email or webhook) so you know if the heartbeat job itself fails with an execution error.
  7. Save and enable the job.

If the heartbeat is missed, Vigilmon alerts you that Rundeck's job scheduler has stalled — the platform is running and serving the web UI but cannot execute jobs. This is the gold standard for monitoring a job scheduling platform: verify it can actually run jobs, not just serve pages.

Why this matters: Rundeck's internal Quartz scheduler can stall after database reconnections, timezone changes, or certain upgrade scenarios. The web UI remains accessible and the login page check passes — only a job-based heartbeat detects a stalled scheduler.

Step 5: Monitor SSL Certificates

Rundeck is typically deployed behind an nginx or Apache reverse proxy for HTTPS. When the SSL certificate expires:

  • Ops engineers can't access the runbook portal (browser TLS error)
  • CI/CD integrations making HTTPS API calls to Rundeck fail
  • Webhook notifications from Rundeck to external services may fail
  • This is likely to happen during an incident when you need Rundeck most
  1. Add Monitor → SSL Certificate.
  2. Domain: rundeck.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days, 1 day.
  5. Click Save.

Let's Encrypt users: If you use Certbot with nginx for Rundeck's reverse proxy, verify the renewal cron job is active with systemctl status certbot.timer. The renewal hook must reload nginx after renewal — check /etc/letsencrypt/renewal-hooks/deploy/ for the reload script.

Step 6: Configure Alerting

In Vigilmon under Settings → Notifications, configure your alert channels:

| Monitor | Trigger | Action | |---|---|---| | Login page | Non-200 or Log In missing | Check systemctl status rundeckd; inspect logs at /var/log/rundeck/ or journalctl -u rundeckd | | API endpoint | Non-200/403 or rundeck missing | API layer issue; check Grails application logs for exceptions | | Job executor heartbeat | Heartbeat missed | Quartz scheduler stalled; restart Rundeck service; check DB connection | | SSL certificate | < 30 days to expiry | Renew via Certbot; reload nginx after renewal |

Alert after: 2 consecutive failures for HTTP monitors (accounts for JVM GC pauses). 1 missed heartbeat for the job executor — a missed heartbeat means a job didn't run, which is always significant.

Common Rundeck Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | JVM OOM kill / crash | Login page unreachable; alert within 60 s | | Database connection failure | Login page returns 500 instead of form; keyword check fails | | Quartz scheduler stall | Login page green, API green; heartbeat missed | | Grails startup failure after upgrade | Login page returns error; API returns non-200 | | Port 4440 firewall block | All HTTP monitors fail; may indicate network change | | SSL certificate expires | SSL monitor alerts at 30-day threshold; API calls fail | | H2 embedded DB corruption | Login page fails; restart may recover or require DB reset | | Reverse proxy misconfiguration | Login page returns 502/503; direct port 4440 may still respond | | DNS misconfiguration | All monitors fire simultaneously |

Rundeck downtime has a deferred blast radius: the web UI may disappear hours before anyone notices that scheduled jobs stopped running. By the time on-call engineers realize nightly backups didn't run or a deployment job is overdue, the failure may be hours old. Vigilmon's combination of login page monitoring, API health checks, and job-executor heartbeats gives you immediate visibility into all three failure modes — so you catch Rundeck failures in seconds and restore runbook automation before any scheduled operations are missed.

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

Monitor your app with Vigilmon

Free plan — 5 monitors, no credit card required. Up and running in 60 seconds.

Start free →
← Back to all articles