tutorial

Monitoring Rush Monorepo Pipelines with Vigilmon: Build Health, pnpm Workspace Uptime & SSL Alerts

How to monitor Microsoft Rush Stack monorepo build and release pipelines with Vigilmon — pnpm workspace health, build orchestration uptime, npm registry availability, and SSL certificate alerts.

Microsoft Rush Stack manages some of the largest JavaScript and TypeScript monorepos in the industry — orchestrating builds across hundreds of packages with strict dependency ordering, pnpm workspaces, and incremental build caching via Rush's build cache. When the infrastructure supporting a Rush monorepo breaks, the failure mode is severe: rush build halts mid-graph, partial builds corrupt workspace state, and CI pipelines exit with unhelpful errors that take hours to diagnose. Vigilmon gives you external visibility into the infrastructure Rush depends on — npm/pnpm registries, build cache servers, CI/CD endpoints, and artifact repositories — so you catch failures before they block your entire development team.

What You'll Build

  • A monitor on the pnpm registry endpoint to catch dependency resolution failures
  • A monitor on Rush's build cache backend (Azure Blob Storage endpoint or custom HTTP cache)
  • A TCP check on your private registry if you host one with Verdaccio or Artifactory
  • SSL certificate monitoring for all Rush infrastructure domains
  • An alerting setup that distinguishes cache misses from full registry outages

Prerequisites

  • A Rush monorepo using Rush Stack (@microsoft/rush) version 5.x or later
  • A rush.json configuration pointing to a registry (npm, Verdaccio, or Artifactory)
  • Optionally: Rush's build cache configured with Azure Blob, AWS S3, or a custom HTTP backend
  • A CI/CD system running rush build and rush publish
  • A free account at vigilmon.online

Step 1: Identify Your Rush Registry Configuration

Rush reads registry configuration from .npmrc in the repo root and from rush.json. Identify your registry:

// rush.json (relevant excerpt)
{
  "npmVersion": "10.0.0",
  "pnpmVersion": "9.0.0",
  "registry": "https://registry.example.com"
}

Or in the common .npmrc:

registry=https://registry.example.com

Test your registry endpoint's health:

# npm-compatible ping (works for Verdaccio, Artifactory, npm)
curl https://registry.example.com/-/ping

# pnpm also respects npm's /-/ping endpoint

Rush uses pnpm under the hood for package installation, so the registry you configure must be pnpm-compatible. All standard npm-compatible registries (Verdaccio, Artifactory, GitHub Packages) support pnpm.

Step 2: Monitor the pnpm Registry Endpoint

Rush's rush update and rush install commands download all packages through the configured registry. If the registry is unreachable, these commands fail for every developer and every CI runner simultaneously.

  1. Log in to Vigilmon → Add Monitor → HTTP.
  2. URL: https://registry.example.com/-/ping (or https://registry.npmjs.org/-/ping if using npm directly).
  3. Check interval: 2 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Keyword: ok (Verdaccio returns {"ok":"true"}; npm returns {"db_name":"registry"}).
  7. Label: Rush pnpm registry ping.
  8. Click Save.

Rush pnpm shrinkwrap: Rush uses pnpm-lock.yaml (or its own common/config/rush/pnpm-lock.yaml) to pin all dependencies. If the registry is down but pnpm's store cache on the CI runner is warm, rush install may still succeed. Vigilmon will alert you that the registry is down even if CI appears green — giving you advance warning before the cache expires or a new CI runner is provisioned.

Step 3: Monitor Rush's Build Cache Backend

Rush's build cache saves rush build task outputs to a remote backend so developers and CI runners can restore cached build artifacts instead of rebuilding from scratch. Rush supports Azure Blob Storage, AWS S3, and custom HTTP cache servers.

Azure Blob Storage (most common):

# Test Azure Blob Storage availability
curl -I "https://your-account.blob.core.windows.net/rush-build-cache?restype=container"
# Returns 200 or 403 (authentication required) when Azure Blob is reachable
  1. Add Monitor → HTTP.
  2. URL: https://your-account.blob.core.windows.net/rush-build-cache?restype=container.
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 403 (Azure returns 403 for unauthenticated requests when the service is healthy — a 403 means Azure is up and the container exists).
  6. Label: Rush build cache (Azure Blob).
  7. Click Save.

Why expect 403? Azure Blob Storage requires authentication for container operations. An unauthenticated request returns 403 Forbidden when the service is healthy — meaning the container exists and Azure is responding. A 503, 502, or connection timeout means Azure Blob is degraded. Monitoring for 403 is the correct way to check availability without storing credentials in Vigilmon.

Custom HTTP build cache:

If you've configured a custom HTTP build cache server (cloudCacheProvider with httpEndpoint in common/config/rush/build-cache.json):

curl -I https://build-cache.example.com/health
  1. URL: https://build-cache.example.com/health.
  2. Expected status: 200.
  3. Label: Rush HTTP build cache.

When the build cache monitor fires, rush build will rebuild everything from source instead of restoring from cache. Builds will succeed but take significantly longer — typically 5–20× longer for large monorepos. Alert your team immediately so they know CI times will be elevated.

Step 4: Monitor the CI/CD Runner for Rush Pipelines

Rush build orchestration runs on CI — typically GitHub Actions, Azure Pipelines, or Jenkins. A degraded CI platform means Rush builds queue indefinitely or never trigger.

For Azure Pipelines (common for Rush-based projects given the Microsoft ecosystem):

curl -I https://dev.azure.com
# Returns 200 when Azure DevOps is operational
  1. Add Monitor → HTTP.
  2. URL: https://dev.azure.com.
  3. Check interval: 5 minutes.
  4. Response timeout: 15 seconds.
  5. Expected status: 200.
  6. Label: Azure DevOps / Pipelines health.
  7. Click Save.

For GitHub Actions:

  1. URL: https://api.github.com.
  2. Expected status: 200.
  3. Label: GitHub Actions CI health.

Rush-specific CI pattern: Rush's rush change and rush publish workflows often run as separate CI jobs with approval gates. A degraded CI platform doesn't just slow builds — it blocks the entire release workflow. Separate monitors for different CI stages (build, publish) help you pinpoint where in the Rush release pipeline the failure occurred.

Step 5: Monitor the Artifact Repository for Published Rush Packages

If your Rush monorepo publishes packages (via rush publish), those packages need to be verifiable after publish. Monitor the published package endpoint to catch silent publish failures:

# Verify a Rush-published package exists in the registry
curl https://registry.example.com/@your-org/your-package/latest
# Returns 200 with package metadata when available
  1. Add Monitor → HTTP.
  2. URL: https://registry.example.com/@your-org/your-package/latest.
  3. Check interval: 30 minutes.
  4. Response timeout: 10 seconds.
  5. Expected status: 200.
  6. Keyword: version.
  7. Label: @your-org/your-package publish verification.
  8. Click Save.

Rush's rush publish creates git tags and bumps versions before publishing. If the publish step fails partway through, you're left with version bumps and git tags but missing npm artifacts — a particularly painful state to recover from.

Step 6: Monitor SSL Certificates for Rush Infrastructure

Rush and pnpm verify TLS certificates when downloading packages. An expired certificate on your registry causes pnpm install to fail with certificate has expired for every developer in the monorepo — simultaneously, with no graceful fallback.

# Check certificate expiry for each domain
openssl s_client -connect registry.example.com:443 2>/dev/null | openssl x509 -noout -dates
openssl s_client -connect build-cache.example.com:443 2>/dev/null | openssl x509 -noout -dates

For each domain:

  1. Add Monitor → SSL Certificate.
  2. Domain: registry.example.com.
  3. Alert when expiry is within: 30 days.
  4. Alert again: 14 days, 7 days, 3 days.
  5. Click Save.

Repeat for build-cache.example.com and any other Rush infrastructure domains.

Rush's strict TLS policy: Rush and pnpm do not support NODE_TLS_REJECT_UNAUTHORIZED=0 as a workaround for certificate issues in most enterprise configurations. The only safe response to an expired certificate is immediate renewal — your 30-day Vigilmon alert window gives you time to renew without emergency pressure.

Step 7: Configure Alerting

In Vigilmon under Settings → Notifications, set up your alert routing:

| Monitor | Trigger | Action | |---|---|---| | pnpm registry ping | Non-200 or keyword missing | All rush install and rush update commands blocked; check registry server health | | Rush build cache (Azure Blob) | Non-403/200 | Builds will succeed but rebuild from scratch; notify team of elevated CI times | | Azure DevOps / GitHub CI | Non-200 | Rush builds queued or not triggering; check CI platform status page | | Package publish verification | Non-200 or version missing | rush publish may have failed partially; audit git tags vs. registry state | | SSL certificate | < 30 days to expiry | Renew certificate; all developers blocked simultaneously if expired |

Alert after: 2 consecutive failures for HTTP monitors; 1 failure for TCP monitors.

Common Rush Monorepo Failure Modes and What Vigilmon Catches

| Scenario | Vigilmon monitor | |---|---| | Private registry (Verdaccio) crashes | Registry ping monitor fires; rush install fails for all developers and CI | | Azure Blob Storage degraded | Build cache monitor fires; rush build completes but ignores cache | | CI platform outage | CI API monitor fires; Rush pipelines queue indefinitely | | Partial rush publish (network drop) | Package verification monitor catches missing packages post-publish | | SSL certificate expires on registry | SSL monitor at 30 days; pnpm TLS error blocks all installations | | Build cache URL changed in config | Build cache TCP/HTTP monitor fires; silent cache miss impacts CI performance | | npm registry rate limiting | Intermittent registry ping failures; rush install timeouts on fresh CI runners | | pnpm lockfile conflict post-merge | Not directly monitorable — but CI failures trigger via pipeline health monitoring |

Rush's build orchestration is designed to be deterministic and reproducible — but it relies on external services that are anything but. When the pnpm registry goes down mid-CI run, when the Azure Blob build cache becomes unavailable, or when an expired certificate cascades into a team-wide installation failure, the impact ripples across every developer in the monorepo simultaneously. Vigilmon gives you the external visibility to catch these failures at the infrastructure level before they become engineering team emergencies.

Start monitoring your Rush monorepo infrastructure 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