tutorial

How to Monitor Release-it Pipelines with Vigilmon

Release-it is the CLI tool that automates versioning, changelog generation, git tagging, npm publishing, and GitHub release creation in a single command. It'...

Release-it is the CLI tool that automates versioning, changelog generation, git tagging, npm publishing, and GitHub release creation in a single command. It's the engine behind many projects' release workflows. But when the services those releases deploy go down — or when the release pipeline itself stops running — Release-it has no built-in monitoring.

In this tutorial you'll add uptime and heartbeat monitoring to Release-it release pipelines and the services they ship using Vigilmon — free tier, no credit card required.

Why monitor Release-it pipelines?

Release-it is often run in CI on a schedule or triggered by pushing to a release branch. Several things can fail silently:

  • npm publish succeeds but service deployment fails — the artifact is live on npm but the running service never updated, leaving production on stale code
  • GitHub release is created but changelog is empty — a misconfigured Release-it plugin generates a release tag with no notes, and nobody notices
  • Scheduled release job stops running — a CI configuration change disables the trigger and releases stop shipping without any error
  • Service degrades after a new release — a dependency change or migration in the new version causes 5xx errors that only surface after deployment

Vigilmon heartbeat monitors catch pipeline stalls; HTTP monitors catch post-release service degradation.

What you'll need

  • A project using Release-it (typically with a CI workflow that runs release-it)
  • A service deployed after each Release-it release
  • A free Vigilmon account

Step 1: Add a health endpoint that exposes the current release version

The most useful health endpoint for a Release-it-managed project tells you which version is currently deployed. This lets you verify that the latest Release-it tag is actually running in production.

For a Node.js service:

const { version, name } = require('./package.json');

app.get('/health', (req, res) => {
  res.json({
    status: 'ok',
    name,
    version,
    uptime: process.uptime()
  });
});

After Release-it bumps 2.1.0 → 2.2.0 and deploys, the health endpoint should show "version":"2.2.0". If it still shows 2.1.0, the deployment silently failed.

For a Go service (using a version variable injected at build time):

var Version = "dev"

http.HandleFunc("/health", func(w http.ResponseWriter, r *http.Request) {
    w.Header().Set("Content-Type", "application/json")
    fmt.Fprintf(w, `{"status":"ok","version":%q}`, Version)
})

Build with: go build -ldflags "-X main.Version=$(git describe --tags --exact-match)" to inject the Release-it tag.

Step 2: Configure Release-it hooks to ping Vigilmon

Release-it supports lifecycle hooks that run shell commands at each stage of the release process. Add a Vigilmon heartbeat ping to the after:release hook:

{
  "$schema": "https://unpkg.com/release-it/schema/release-it.json",
  "git": {
    "commitMessage": "chore: release v${version}",
    "tagName": "v${version}"
  },
  "npm": {
    "publish": true
  },
  "hooks": {
    "after:bump": "echo 'Version bumped to ${version}'",
    "after:npm:release": "echo 'Published to npm'",
    "after:release": "curl -fsS -X POST \"$VIGILMON_RELEASE_HEARTBEAT_URL\" --max-time 10 --retry 3 && echo 'Vigilmon heartbeat sent'"
  },
  "github": {
    "release": true,
    "releaseName": "Release v${version}"
  }
}

Set VIGILMON_RELEASE_HEARTBEAT_URL as an environment variable in your CI secrets. The after:release hook fires only when all release steps complete successfully — if npm publish fails or the GitHub release creation errors, the hook doesn't run and no ping reaches Vigilmon.

Step 3: Set up heartbeat monitoring in Vigilmon

Create a heartbeat monitor for your Release-it pipeline:

  1. Log in to vigilmon.online and go to New Monitor → Heartbeat
  2. Name it Release-it — main
  3. Set the expected interval to your release cadence:
    • Weekly releases → 8 days (7 days + 1 day grace)
    • Bi-weekly releases → 15 days
    • Continuous releases (every merge) → 48 hours
  4. Set the grace period to 4 hours
  5. Save and copy the ping URL → store it as VIGILMON_RELEASE_HEARTBEAT_URL in CI

If your team stops merging release commits or if CI breaks, no ping arrives after the expected interval and Vigilmon alerts you.

Step 4: Set up HTTP monitoring for deployed services

Point Vigilmon at each service's health endpoint to catch post-release degradation:

  1. Go to Monitors → New Monitor → HTTP / HTTPS
  2. Set the URL to your health endpoint, e.g. https://api.example.com/health
  3. Set the check interval to 1 minute
  4. Under Expected response, set:
    • Status code: 200
    • (Optional) Response body contains: "status":"ok"
  5. Save

Vigilmon checks every minute from multiple regions. Any non-200 response — including a startup failure from a bad release — opens an incident.

Step 5: Add CI pipeline heartbeat monitoring

If Release-it runs in CI (GitHub Actions, GitLab CI, CircleCI), add a dedicated CI heartbeat monitor separate from the Release-it release heartbeat:

# .github/workflows/release.yml
name: Release

on:
  push:
    branches: [main]

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
          token: ${{ secrets.GITHUB_TOKEN }}

      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          registry-url: 'https://registry.npmjs.org'

      - run: npm ci

      - name: Configure git
        run: |
          git config user.email "ci@example.com"
          git config user.name "CI"

      - name: Run Release-it
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
          VIGILMON_RELEASE_HEARTBEAT_URL: ${{ secrets.VIGILMON_RELEASE_HEARTBEAT_URL }}
        run: npx release-it --ci

      - name: Deploy updated service
        run: ./scripts/deploy.sh

      - name: Smoke test after deploy
        run: |
          sleep 10
          curl -sf https://api.example.com/health

      - name: Ping Vigilmon — deploy complete
        if: success()
        run: |
          curl -fsS -X POST "${{ secrets.VIGILMON_DEPLOY_HEARTBEAT_URL }}" \
            --max-time 10 --retry 3

Use two separate heartbeat monitors:

  • Release-it — main: pinged by the Release-it after:release hook (confirms packages released)
  • Deploy — production: pinged after the deploy step (confirms service updated)

Step 6: Track key metrics

| Metric | What it catches | |---|---| | HTTP response code | Service crash after release, bad deploy | | HTTP response body version | Old version still serving — deploy silently failed | | HTTP response time | Performance regression introduced in new release | | Release heartbeat | Release cadence stalled, CI trigger disabled | | Deploy heartbeat | Release published but service never updated | | TCP port reachability | Service failed to start after deploy |

Set a response-time alert threshold (e.g. alert if > 1 s) to detect latency regressions introduced by a Release-it-triggered deploy.

Step 7: Configure alert channels

  1. Go to Alert Channels → Add Channel
  2. Choose Email, Slack webhook, or PagerDuty
  3. Assign channels to your HTTP monitors and heartbeat monitors
  4. For production HTTP monitors, trigger on 1 failed check
  5. For release heartbeat monitors, trigger after the grace period expires

When a heartbeat is missed:

🔴 MISSED HEARTBEAT: Release-it — main
Last ping: 10 days ago
Expected interval: 7 days

No release has shipped in 10 days. Check CI pipeline status.

When service health fails after a deploy:

🔴 DOWN: api.example.com/health
Duration: 4 minutes
Last response: 503

Check deploy logs — service may have failed to start after the latest Release-it deploy.

Step 8: Create a status page

If Release-it manages multiple packages and services (a common monorepo pattern), a Vigilmon status page surfaces all service health in one view:

  1. Go to Status Pages → New Status Page
  2. Name it (e.g. "Production Services")
  3. Add all your HTTP monitors and TCP monitors
  4. Publish and share with your team

This is especially useful in the minutes after a Release-it run — team members can watch the status page to confirm all services came up healthy after the deploy.

Conclusion

Release-it automates everything from version bump to GitHub release to npm publish. Vigilmon closes the observability gap that follows: confirming the pipeline ran on schedule, verifying deployed services are healthy, and catching the version mismatch that reveals a deploy silently failed. Add the after:release hook, create a heartbeat monitor for your release cadence, and set up a one-minute HTTP monitor on each deployed service — you'll have full release pipeline visibility in under fifteen minutes.

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