tutorial

Monitoring Updatecli with Vigilmon

Updatecli automates dependency version bumps across Helm charts, Dockerfiles, and any file type — here's how to monitor pipeline health, source fetch success, PR creation, and API rate limits with Vigilmon.

Updatecli is an open-source GitOps tool that automates dependency version updates across any file type and any ecosystem. Where Dependabot covers specific ecosystems like npm and GitHub Actions, Updatecli works on anything you can express in a manifest: Helm chart versions in values.yaml, Docker image tags in Kubernetes manifests, GitHub release versions in version.txt, Terraform module versions, and custom file patterns across multiple repositories. It runs as a CLI in CI/CD pipelines or as a standalone cron job, reading upstream sources and creating pull requests or committing version bumps automatically.

When Updatecli fails silently — a rate-limited GitHub API call, a stale PAT, a broken manifest after an Updatecli version upgrade — your dependencies stop being updated. You might not notice for weeks, until a security advisory lands for a version you should have bumped automatically. Vigilmon gives you pipeline health monitoring, source fetch success tracking, and PR creation alerting for every Updatecli run.

What You'll Set Up

  • Pipeline run health heartbeat (exit code monitoring)
  • Source fetch success rate tracking (GitHub API, Docker Hub, npm)
  • PR creation health monitoring
  • Manifest parse health check
  • Pipeline duration alert (approaching CI timeout)
  • External API rate limit monitoring
  • SCM authentication health check

Prerequisites

  • Updatecli configured and running in CI/CD or as a standalone cron job
  • Updatecli manifests stored in your repository
  • A free Vigilmon account

Why Monitoring Updatecli Matters

Updatecli is a background maintenance tool — when it works, you never think about it. When it silently fails, your dependencies freeze at their last-successfully-updated version and you lose the security and stability benefits of automated updates. The failure modes are subtle:

  • A GitHub PAT expires and PR creation fails, but Updatecli exits 0 because the source fetch succeeded
  • Docker Hub rate limiting causes sporadic source fetch failures that look intermittent
  • A Updatecli version upgrade breaks a manifest schema and updatecli apply exits non-zero silently in a CI job with continue-on-error: true
  • The CI pipeline hits its time limit and kills the Updatecli job mid-run, leaving partial updates

None of these failures produce a visible error in your dashboard without explicit monitoring.

Step 1: Monitor Pipeline Run Health (Exit Code)

The most fundamental signal is whether updatecli apply or updatecli diff exited successfully. A non-zero exit code means at least one source fetch, condition evaluation, or target update failed.

In GitHub Actions

Add a Vigilmon heartbeat step that only runs on success:

name: Update Dependencies

on:
  schedule:
    - cron: '0 6 * * *'  # Daily at 6am
  workflow_dispatch:

jobs:
  updatecli:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install Updatecli
        run: |
          curl -sSL https://github.com/updatecli/updatecli/releases/latest/download/updatecli_Linux_x86_64.tar.gz | tar xz
          sudo mv updatecli /usr/local/bin/

      - name: Run Updatecli
        id: updatecli
        run: updatecli apply --config ./updatecli/
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

      - name: Notify Vigilmon (success only)
        if: success()
        run: curl -fsS "https://vigilmon.online/api/v1/heartbeats/${{ secrets.VIGILMON_HEARTBEAT_ID }}"

Set the Vigilmon heartbeat interval to 25 hours (the pipeline runs daily, plus 1 hour grace). If the heartbeat is not received within 25 hours, you get an alert.

In a Standalone Cron Job

#!/bin/bash
updatecli apply --config /etc/updatecli/
EXIT_CODE=$?

if [ "$EXIT_CODE" -eq 0 ]; then
  curl -fsS --retry 3 "https://vigilmon.online/api/v1/heartbeats/YOUR_HEARTBEAT_ID" > /dev/null
fi

Step 2: Track Source Fetch Success Rate

Updatecli queries multiple upstream APIs to find the latest version of each dependency: GitHub Releases API, Docker Hub API, npm registry, Helm repository indexes, PyPI. Rate limiting or API outages cause source fetch failures that block updates.

Use Updatecli's --output flag to write structured JSON output and parse it for fetch failures:

#!/bin/bash
updatecli apply --config ./updatecli/ 2>&1 | tee /tmp/updatecli_output.txt
EXIT_CODE=$?

# Count source errors from the output
SOURCE_ERRORS=$(grep -c "source.*failed\|ERROR.*source\|rate limit" /tmp/updatecli_output.txt || true)
TOTAL_SOURCES=$(grep -c "source.*ok\|source.*failed\|ERROR.*source" /tmp/updatecli_output.txt || true)

if [ "$TOTAL_SOURCES" -gt 0 ] && [ "$EXIT_CODE" -eq 0 ] && [ "$SOURCE_ERRORS" -eq 0 ]; then
  curl -fsS --retry 3 "https://vigilmon.online/api/v1/heartbeats/YOUR_HEARTBEAT_ID" > /dev/null
fi

For a finer-grained view, create separate Vigilmon heartbeats for different source types — one for GitHub API sources, one for Docker Hub, one for npm — and conditionally send each based on the relevant log lines.

Step 3: Monitor PR Creation Health

Updatecli creates pull requests via the GitHub API (or GitLab, Gitea, Bitbucket). PR creation failures are the most common silent failure mode: the source fetch succeeds (correct new version found), the condition passes, but the PR creation fails due to an expired PAT, insufficient token permissions, or SCM API rate limiting.

Wrap the Updatecli run with explicit PR creation detection:

#!/bin/bash
OUTPUT=$(updatecli apply --config ./updatecli/ 2>&1)
EXIT_CODE=$?

# Check if PRs were expected (targets changed) and whether they were created
TARGETS_CHANGED=$(echo "$OUTPUT" | grep -c "changed\|updated" || true)
PR_CREATED=$(echo "$OUTPUT" | grep -c "Pull Request.*created\|PullRequest.*created" || true)
PR_ERROR=$(echo "$OUTPUT" | grep -c "Error.*Pull Request\|failed.*pull request\|authentication\|forbidden" || true)

if [ "$EXIT_CODE" -eq 0 ] && [ "$PR_ERROR" -eq 0 ]; then
  curl -fsS --retry 3 "https://vigilmon.online/api/v1/heartbeats/YOUR_HEARTBEAT_ID" > /dev/null
fi

In GitHub Actions, you can also check the SCM health separately:

- name: Verify GitHub Token scope
  run: |
    SCOPES=$(curl -sI -H "Authorization: token $GITHUB_TOKEN" \
      https://api.github.com/user | grep x-oauth-scopes)
    echo "Token scopes: $SCOPES"
    # Fail loudly if repo scope is missing
    echo "$SCOPES" | grep -q "repo" || (echo "Token missing repo scope" && exit 1)

Step 4: Manifest Parse Health

Updatecli YAML/HCL manifests can break after a Updatecli version upgrade if the schema changed, or if someone manually edits a manifest incorrectly. A parse error prevents any updates in that manifest file from running, but other manifests may continue to work — making the failure easy to miss.

Use updatecli diff (dry run) as a parse health check separate from the production apply run:

#!/bin/bash
# Run diff as a manifest health check (no PR creation)
updatecli diff --config ./updatecli/ 2>&1 | tee /tmp/updatecli_diff.txt
DIFF_EXIT=$?

PARSE_ERRORS=$(grep -c "yaml: unmarshal\|failed to parse\|manifest.*invalid\|error unmarshaling" /tmp/updatecli_diff.txt || true)

if [ "$DIFF_EXIT" -eq 0 ] && [ "$PARSE_ERRORS" -eq 0 ]; then
  curl -fsS --retry 3 "https://vigilmon.online/api/v1/heartbeats/YOUR_HEARTBEAT_ID" > /dev/null
fi

Run this check in a CI step before the production apply run. Schedule the Vigilmon heartbeat to match your CI frequency. A parse health failure should block the apply step to prevent partial updates.

Step 5: Pipeline Duration Alert

Updatecli queries potentially dozens of upstream APIs per run. If external APIs are slow or if the number of sources has grown significantly, a run that normally takes 3 minutes can balloon to 20+ minutes and hit the CI job timeout. When the job is killed mid-run, Updatecli exits non-zero and may leave a partial state (some PRs created, others not).

Track pipeline duration and alert when it approaches your CI timeout:

#!/bin/bash
START=$(date +%s)
updatecli apply --config ./updatecli/
EXIT_CODE=$?
END=$(date +%s)

ELAPSED=$(( END - START ))
CI_TIMEOUT=1800  # 30 minutes
WARNING_THRESHOLD=1200  # Alert when > 20 minutes

if [ "$EXIT_CODE" -eq 0 ] && [ "$ELAPSED" -lt "$WARNING_THRESHOLD" ]; then
  curl -fsS --retry 3 "https://vigilmon.online/api/v1/heartbeats/YOUR_HEARTBEAT_ID" > /dev/null
fi

# Log duration for trend tracking
echo "$(date -u +%Y-%m-%dT%H:%M:%SZ) duration=${ELAPSED}s exit=${EXIT_CODE}" \
  >> /var/log/updatecli-duration.log

If duration consistently grows, consider splitting large manifests into smaller groups and running them in parallel CI jobs.

Step 6: External API Rate Limit Monitoring

GitHub REST API (60 unauthenticated requests/hour, 5000 with PAT), Docker Hub (100 pulls/6h for anonymous, 200 with free account), and npm (public, high-limit but not unlimited) can all rate-limit Updatecli when you have many sources.

Monitor rate limit headroom proactively:

GitHub API Rate Limit

#!/bin/bash
RATE_INFO=$(curl -s -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/rate_limit)

REMAINING=$(echo "$RATE_INFO" | python3 -c \
  "import sys,json; d=json.load(sys.stdin); print(d['rate']['remaining'])" 2>/dev/null || echo 0)
LIMIT=$(echo "$RATE_INFO" | python3 -c \
  "import sys,json; d=json.load(sys.stdin); print(d['rate']['limit'])" 2>/dev/null || echo 5000)

# Alert when less than 20% of rate limit remaining
THRESHOLD=$(( LIMIT / 5 ))
if [ "$REMAINING" -gt "$THRESHOLD" ]; then
  curl -fsS --retry 3 "https://vigilmon.online/api/v1/heartbeats/YOUR_HEARTBEAT_ID" > /dev/null
fi

Schedule every 30 minutes. Name this heartbeat "Updatecli GitHub Rate Limit". If you have many Updatecli sources that query GitHub, consider using a GitHub App token instead of a PAT — App tokens have a separate, higher rate limit.

Step 7: SCM Authentication Health

Updatecli needs a valid GitHub token (or GitLab/Gitea equivalent) to create pull requests. PATs expire, GitHub Apps can have their permissions revoked, and token rotation policies can invalidate tokens silently.

Check authentication health before each Updatecli run:

#!/bin/bash
# Validate GitHub token before Updatecli run
AUTH_STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
  -H "Authorization: token $GITHUB_TOKEN" \
  https://api.github.com/user)

if [ "$AUTH_STATUS" = "200" ]; then
  # Token valid — run Updatecli
  updatecli apply --config ./updatecli/
  if [ $? -eq 0 ]; then
    curl -fsS --retry 3 "https://vigilmon.online/api/v1/heartbeats/YOUR_HEARTBEAT_ID" > /dev/null
  fi
else
  echo "GitHub token authentication failed (HTTP $AUTH_STATUS)" >&2
  # Don't send heartbeat — Vigilmon will alert on missed heartbeat
fi

In GitHub Actions, the GITHUB_TOKEN is automatically generated per-run and never expires. For deployments using personal access tokens or GitHub App tokens with explicit expiry dates, add a token expiry check:

#!/bin/bash
# Check PAT expiry via GitHub API (returns expiry in response headers)
EXPIRY=$(curl -sI -H "Authorization: token $GITHUB_PAT" \
  https://api.github.com/user | grep -i "github-authentication-token-expiration" | \
  awk '{print $2}')

if [ -n "$EXPIRY" ]; then
  echo "Token expires: $EXPIRY"
  # Alert via Vigilmon if expiry is within 7 days
  EXPIRY_EPOCH=$(date -d "$EXPIRY" +%s 2>/dev/null)
  NOW_EPOCH=$(date +%s)
  DAYS_LEFT=$(( (EXPIRY_EPOCH - NOW_EPOCH) / 86400 ))
  if [ "$DAYS_LEFT" -gt 7 ]; then
    curl -fsS --retry 3 "https://vigilmon.online/api/v1/heartbeats/YOUR_HEARTBEAT_ID" > /dev/null
  fi
fi

Alerting Configuration

| Monitor | Alert condition | Recommended channel | |---------|----------------|---------------------| | Pipeline run heartbeat | Missed heartbeat | Slack | | Manifest parse heartbeat | Missed heartbeat | Slack | | PR creation heartbeat | Missed heartbeat | Slack | | GitHub rate limit heartbeat | Missed heartbeat | Slack | | SCM auth heartbeat | Missed heartbeat | PagerDuty | | Pipeline duration heartbeat | Missed heartbeat (long duration) | Slack |

SCM authentication failure is the highest severity — it means all PR creation is broken until the token is rotated. Send it to PagerDuty or equivalent. Other failures can go to Slack for async triage.

Comparing Updatecli to Dependabot Monitoring

Dependabot's update failures are visible in the GitHub UI. Updatecli's failures are silent by default — it runs wherever you configure it, logs to wherever your CI logs go, and has no built-in dashboard. This is the gap Vigilmon fills: a central place to see whether your Updatecli pipelines are running, succeeding, and reaching their targets.

If you run Updatecli across multiple repositories or environments, create a separate Vigilmon heartbeat for each pipeline. Name them clearly (e.g., "Updatecli — frontend deps", "Updatecli — infrastructure charts") so you can trace an alert to the specific pipeline that failed.

Troubleshooting Common Updatecli Failures

Non-zero exit, source fetch failed: Check the Updatecli output for the specific source that failed. Common causes: API rate limiting, network connectivity from CI to the source (Docker Hub, npm), or the upstream package was deleted/renamed.

Zero exit, no PRs created when expected: The Updatecli condition evaluated to false — either the version constraint in the manifest prevented the update, or the condition check (e.g., "target file must exist") was not met. Run updatecli diff and look for condition lines with SKIPPED.

Manifest parse error after Updatecli upgrade: Run updatecli validate --config ./updatecli/ to check each manifest. Refer to the Updatecli changelog for breaking schema changes and migrate the affected manifest fields.

Pipeline duration growing: Profile which sources are slow by adding --debug flag. Slow sources are usually rate-limited APIs with retry delays. Consider caching source results where Updatecli supports it, or splitting the manifest into multiple parallel CI jobs.

PAT expired: Rotate the token, update the CI secret, and re-run the pipeline. Consider switching to a GitHub App with a long-lived installation token to avoid PAT expiry surprises.

Conclusion

Updatecli is a powerful set-and-forget dependency automation tool — but "set and forget" is only safe when you know it's actually running. With Vigilmon heartbeat monitors for pipeline health, source fetch success, PR creation, manifest validity, and API rate limits, you get early warning on every failure mode before your dependency updates silently stop. Add these monitors when you first set up Updatecli, not after you notice a six-week gap in your PRs.

Get started 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