How to Monitor Changesets Release Pipelines with Vigilmon

Changesets is the versioning and changelog management tool used by monorepo teams to coordinate package releases. It tracks which packages changed, bumps versions automatically, and publishes to npm. But when the services those packages power go down after a release — or when the release pipeline itself stalls — Changesets has no mechanism to alert you.

In this tutorial you'll add uptime and heartbeat monitoring to both your Changesets release pipelines and the services they deploy using Vigilmon — free tier, no credit card required.

Why monitor Changesets release pipelines?

Changesets is typically used in automated release workflows triggered by merges to main. In those pipelines several things can go wrong silently:

• npm publish fails after version bump — the package versions are incremented but the artifacts never reach the registry, and consumers get stale packages without knowing it
• Post-release service deployment silently fails — the CI job that deploys updated services after a Changesets release exits with an error that nobody notices
• Changelog generation completes but pull request stalls — the automated "Version Packages" PR sits unmerged for days while consumers wait for a release
• Packages publish but dependent services aren't restarted — a new package version is live on npm but the production service is still running the old code

Vigilmon's heartbeat monitors catch pipeline stalls; HTTP monitors catch service degradation after releases.

What you'll need

• A monorepo using Changesets with a CI-based release pipeline
• Services that get deployed after Changesets publishes packages
• A free Vigilmon account

Step 1: Add a health endpoint to your deployed services

Services deployed by your Changesets pipeline should expose a health endpoint that includes the package version currently running. This makes it easy to verify that a new release actually deployed.

For a Node.js service:

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

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

After a Changesets release bumps 1.2.3 → 1.3.0, the health endpoint response should show "version":"1.3.0" within minutes of deployment. If it still shows 1.2.3, the deploy silently failed.

Step 2: Set up HTTP monitoring in Vigilmon

Point Vigilmon at each service's health endpoint:

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

Any non-200 response or timeout — including degradation caused by a bad release — opens a Vigilmon incident immediately.

Step 3: Add heartbeat monitoring to your release pipeline

The Changesets release workflow typically has two phases: "version packages" (opens a PR) and "publish" (runs after the PR merges). Add a heartbeat monitor to the publish phase to confirm releases actually ship on schedule.

In Vigilmon:

1. Go to New Monitor → Heartbeat
2. Name it Changesets Publish — main
3. Set expected interval to your release cadence (e.g. weekly = 8 days to account for drift)
4. Copy the ping URL

In your GitHub Actions release workflow:

# .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

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

      - run: npm ci

      - name: Create Release Pull Request or Publish
        id: changesets
        uses: changesets/action@v1
        with:
          publish: npm run release
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          NPM_TOKEN: ${{ secrets.NPM_TOKEN }}

      - name: Ping Vigilmon — packages published
        if: steps.changesets.outputs.published == 'true'
        run: |
          curl -fsS -X POST "${{ secrets.VIGILMON_RELEASE_HEARTBEAT_URL }}" \
            --max-time 10 --retry 3

The heartbeat ping only fires when changesets/action confirms packages were actually published (outputs.published == 'true'). A release run that only bumps versions and opens a PR does not ping — meaning if your team stops merging the version PR, Vigilmon alerts after your expected release interval.

Step 4: Monitor post-release deployments

After packages publish, your pipeline likely deploys updated services. Add a second heartbeat for the deployment step:

  deploy:
    needs: release
    runs-on: ubuntu-latest
    if: needs.release.outputs.published == 'true'
    steps:
      - name: Deploy updated services
        run: ./scripts/deploy.sh

      - name: Smoke test
        run: 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

Create a separate Vigilmon heartbeat monitor for this step with the same cadence as your release pipeline. If packages publish but the deployment silently fails, the deploy heartbeat is missed and you get alerted — even though the release pipeline itself shows green.

Step 5: Track key metrics

| Metric | What it catches | |---|---| | HTTP response code | Service crash after release, bad deploy | | HTTP response body version | Old version still running — deploy silently failed | | HTTP response time | Performance regression in a new release | | Release pipeline heartbeat | Publish cadence stalled, team stopped merging version PRs | | Deploy pipeline heartbeat | Release published but service never updated |

Step 6: 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 monitors, trigger on 1 failed check; for release heartbeats, trigger after the grace period

A useful Slack message when a release heartbeat is missed:

🔴 MISSED HEARTBEAT: Changesets Publish — main
Last ping: 10 days ago
Expected interval: 7 days

Your release pipeline may have stalled. Check the "Version Packages" PR status.

Step 7: Monitor npm registry reachability

If your release pipeline depends on the npm registry and the registry is degraded, npm publish will fail silently or hang. Add a basic HTTP monitor for the registry endpoint your CI uses:

1. Monitor → New Monitor → HTTP / HTTPS
2. URL: https://registry.npmjs.org
3. Interval: 5 minutes
4. Expected: status 200

This gives you early warning during npm registry incidents so you know to hold releases rather than publish into a degraded state.

Conclusion

Changesets automates the tedious parts of monorepo versioning — but it doesn't monitor itself. Vigilmon fills that gap: heartbeat monitors confirm your release pipeline is shipping on schedule, HTTP monitors confirm deployed services are healthy, and version fields in health endpoints verify the right release is actually running. Set up the Changesets heartbeat in your CI workflow and a one-minute HTTP monitor on each deployed service — you'll know about release pipeline stalls and post-release regressions before your users do.

Get started free at vigilmon.online.