Monitoring Travis CI Pipelines with Vigilmon: Catch Silent CI/CD Failures

Your weekly security scan stopped running a month ago. Nobody noticed until an audit. Travis CI had no errors to report — the build simply wasn't being triggered anymore. Build notifications only fire on failures, and you can't fail if you never run.

This is the silent CI/CD failure problem. HTTP monitors can't catch it because there's nothing to ping. The fix is heartbeat monitoring: your build pings a unique URL at the end of every successful run, and if Vigilmon doesn't receive that ping within the expected window, you get alerted.

This tutorial shows you how to instrument Travis CI builds with Vigilmon heartbeat monitors to catch failures before your team does.

What You'll Cover

• Heartbeat monitoring for scheduled Travis CI builds
• Catching builds that stop triggering entirely
• Alerting on long-running or stuck jobs
• Multi-environment CI monitoring (staging and production)
• Detecting cron job drift in Travis CI

Prerequisites

• A Travis CI project with at least one build configuration
• A free account at vigilmon.online

The Problem: What Standard Travis CI Monitoring Misses

Travis CI has built-in email notifications — but they only fire when a build fails. They won't alert you when:

• A Travis CI cron job is deleted or disabled in the UI
• A build is allowed to fail (allow_failures) and silently starts failing permanently
• A deployment stage completes but the actual deploy step is skipped due to a condition
• Travis CI runs out of credits (on the hosted plan) and builds queue indefinitely

Vigilmon's heartbeat pattern closes all of these gaps.

Step 1: Create a Heartbeat Monitor in Vigilmon

A heartbeat monitor expects a ping on a regular interval. No ping → alert.

1. Log in to Vigilmon and click New Monitor → Heartbeat.
2. Give it a name like Nightly Tests — main.
3. Set the Expected interval to match your build schedule. For a nightly cron, use 24 hours. For hourly CI, use 90 minutes (adds a 50% buffer).
4. Set the Grace period to 30 minutes for short intervals, or 1 hour for daily jobs. This prevents false alerts from slight schedule drift.
5. Save and copy the Ping URL — it looks like https://vigilmon.online/api/heartbeat/<unique-id>.

Step 2: Add the Heartbeat Ping to a Scheduled Build

Store the heartbeat URL as a Travis CI encrypted environment variable. In your repository settings on travis-ci.com, go to Settings → Environment Variables → Add:

• Name: VIGILMON_NIGHTLY_HEARTBEAT_URL
• Value: the ping URL from Step 1
• Display value in build log: off

Here's a complete .travis.yml example with Vigilmon instrumentation:

# .travis.yml
language: node_js
node_js:
  - "20"

cache:
  directories:
    - node_modules

install:
  - npm ci

script:
  - npm test

after_success:
  - |
    curl -fsS -X POST "$VIGILMON_NIGHTLY_HEARTBEAT_URL" \
      --max-time 10 \
      --retry 3 \
      --retry-delay 2

Key points about this setup:

• after_success — this stage only runs when all script steps exit with code 0. If tests fail, after_success is skipped and no ping is sent.
• --retry 3 — transient network issues won't cause a false "missed heartbeat" alert.
• --max-time 10 — the ping step won't hang and block the build.

Step 3: Monitor Your Deployment Pipeline

Heartbeats are even more valuable for deployment pipelines — a silently stuck deploy leaves production stale without any error to page you.

# .travis.yml (with deployment stage)
language: node_js
node_js:
  - "20"

stages:
  - test
  - name: deploy
    if: branch = main AND type != pull_request

jobs:
  include:
    - stage: test
      script: npm test

    - stage: deploy
      script:
        - npm run build
        - ./scripts/deploy.sh production
        - npm run test:smoke
      after_success:
        - |
          curl -fsS -X POST "$VIGILMON_DEPLOY_PROD_HEARTBEAT_URL" \
            --max-time 10 \
            --retry 3

Create a separate heartbeat monitor for this deployment stage with an interval of 48 hours (or however often you expect to deploy). If no successful deployment reaches production within that window, Vigilmon pages you.

Step 4: Detect Travis CI Cron Job Drift

Travis CI supports Cron Jobs configured in the repository settings UI. These cron jobs are fragile: if a repository is migrated, forked, or the cron is accidentally deleted, it stops firing silently. There's no built-in alerting for a cron that just stops.

Vigilmon's heartbeat monitor catches this automatically — if the cron misses a run for any reason, no ping arrives, and you get alerted.

To make the signal even more reliable, add metadata to the heartbeat payload:

after_success:
  - |
    curl -fsS -X POST "$VIGILMON_NIGHTLY_HEARTBEAT_URL" \
      -H "Content-Type: application/json" \
      -d "{\"repo\": \"$TRAVIS_REPO_SLUG\", \"build_id\": \"$TRAVIS_BUILD_ID\", \"branch\": \"$TRAVIS_BRANCH\"}" \
      --max-time 10 \
      --retry 3

Vigilmon accepts the body but doesn't require it — it only cares whether the ping arrived within the grace period.

Step 5: Multi-Environment Monitoring

For teams with staging and production pipelines, create one heartbeat monitor per environment per build stage:

| Build stage | Environment | Monitor name | Interval | |---|---|---|---| | Deploy stage | Production | Deploy → Production | 48 h | | Deploy stage | Staging | Deploy → Staging | 24 h | | Nightly tests | main | Nightly Tests — main | 25 h | | Weekly security scan | — | Weekly Security Scan | 8 days |

Use separate environment variables per environment, resolved dynamically:

after_success:
  - |
    if [ "$TRAVIS_BRANCH" = "main" ]; then
      HEARTBEAT_URL="$VIGILMON_DEPLOY_PROD_HEARTBEAT_URL"
    else
      HEARTBEAT_URL="$VIGILMON_DEPLOY_STAGING_HEARTBEAT_URL"
    fi
    curl -fsS -X POST "$HEARTBEAT_URL" --max-time 10

Step 6: Alert Channels

In Vigilmon, go to Notifications → New Channel and configure:

• Email — immediate alert when a heartbeat is missed
• Slack webhook — ping your #alerts or #ci-cd channel

When a build stops pinging:

🔴 MISSED HEARTBEAT: Nightly Tests — main
Last ping: 26 hours ago
Expected interval: 24 hours

When it resumes:

✅ HEARTBEAT RECOVERED: Nightly Tests — main
Gap: 26 hours

Step 7: Protect Against allow_failures Silent Breakage

Travis CI's allow_failures setting is a common silent failure trap: a job that's allowed to fail will never trigger an email notification even when it permanently breaks. Once the failure becomes permanent, the team forgets the job was ever supposed to succeed.

Heartbeat monitoring sidesteps this: if the after_success stage never fires (because the job is always failing), no ping arrives and Vigilmon alerts you regardless of your allow_failures settings.

Complete Build Template

Here's a reusable snippet you can copy into any .travis.yml:

# Add this to any stage you want heartbeat monitoring on
after_success:
  - |
    curl -fsS -X POST "$VIGILMON_HEARTBEAT_URL" \
      --max-time 10 \
      --retry 3 \
      --retry-delay 2

Replace VIGILMON_HEARTBEAT_URL with the specific environment variable name for that build's monitor (use one heartbeat monitor per build stage).

What You're Now Catching

| Silent failure mode | How Vigilmon detects it | |---|---| | Travis CI cron job deleted or disabled | No ping arrives → alert after grace period | | Build credits exhausted, builds queued forever | No ping arrives → alert after grace period | | allow_failures job permanently broken | No after_success ping → alert | | Job hung on a stuck step | Build timeout → no ping → alert | | Deploy stage skipped due to branch condition | No ping on deploy stage → alert | | Deploy pipeline stopped shipping | Deploy heartbeat missed → alert |

Travis CI is reliable — until it quietly stops working. Vigilmon's heartbeat monitors give you the external signal that Travis CI itself can't provide: a definitive alert when your CI/CD pipeline hasn't run in longer than expected.

Add heartbeat monitoring to your Travis CI builds today — register free at vigilmon.online.