How to Monitor NX Cloud with Vigilmon

NX Cloud provides distributed task execution (DTE) and remote caching for Nx monorepos, dramatically cutting CI build times by distributing test, lint, and build tasks across multiple agents and caching their outputs in the cloud. When NX Cloud is healthy, a 20-minute CI run becomes 3 minutes. When it isn't, those same builds hang indefinitely or fall back to fully local execution without any alert.

This tutorial shows you how to monitor your NX Cloud connectivity, your CI pipeline's task-execution endpoints, and any application services your Nx monorepo builds — using Vigilmon for external uptime monitoring.

Why monitor NX Cloud?

NX Cloud sits in the critical path of every CI build for teams using Nx. When it degrades, the effects cascade:

• Cache misses across the board — if the NX Cloud cache endpoint is unreachable, every task executes locally, inflating CI times 5–10x
• DTE agent starvation — distributed task execution agents fail to pick up work if the NX Cloud orchestration endpoint is down
• Silent fallback — Nx is designed to fall back gracefully to local execution, which means NX Cloud outages often go undetected until engineers notice slow builds
• Application regressions from uncached artifacts — if a build publishes to your registry only when the cache misses, a cache outage can trigger unexpected artifact republishing

Beyond the NX Cloud service itself, the applications your Nx monorepo builds and deploys need their own uptime monitoring — Nx doesn't know whether the service it just deployed is actually serving traffic.

What you'll need

• An Nx monorepo configured with NX Cloud (nx.json with nxCloudAccessToken)
• One or more applications deployed from the monorepo
• A free Vigilmon account

Step 1: Verify your NX Cloud configuration

Check that NX Cloud is active in your nx.json:

{
  "nxCloudAccessToken": "your-access-token",
  "tasksRunnerOptions": {
    "default": {
      "runner": "nx-cloud",
      "options": {
        "cacheableOperations": ["build", "test", "lint", "e2e"],
        "url": "https://cloud.nx.app"
      }
    }
  }
}

Run a quick connectivity check:

npx nx connect-to-nx-cloud
# Or check cache hit status:
npx nx show project my-app --json | jq '.targets'

If the NX Cloud endpoint is reachable, your next nx build should show cache hits in the terminal output.

Step 2: Monitor the NX Cloud API endpoint

NX Cloud's primary connectivity point is https://cloud.nx.app. While Nx Inc. runs this service, you can monitor its availability from your own account to track outages that affect your builds.

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS
3. Set the URL to https://cloud.nx.app
4. Set the check interval to 1 minute
5. Configure Expected response:
   • Status code: 200 (or 2xx — the NX Cloud home page returns 200)
6. Save the monitor

When this monitor goes red, you know immediately that NX Cloud is the source of slow CI builds — not your build configuration.

Step 3: Add a health endpoint to your deployed applications

Nx builds your apps; Vigilmon monitors whether they're actually running. Add a /health route to each application deployed from your monorepo.

For a Next.js app (via App Router):

// apps/web/app/api/health/route.ts
import { NextResponse } from 'next/server';

export async function GET() {
  return NextResponse.json({ status: 'ok', app: 'web' });
}

For a NestJS API (common in Nx monorepos):

// apps/api/src/health/health.controller.ts
import { Controller, Get } from '@nestjs/common';

@Controller('health')
export class HealthController {
  @Get()
  check() {
    return { status: 'ok', app: 'api' };
  }
}

For an Express app:

// apps/server/src/main.js
app.get('/health', (req, res) => {
  res.json({ status: 'ok', app: 'server', uptime: process.uptime() });
});

These endpoints give Vigilmon a clear signal to probe after each deployment.

Step 4: Monitor deployed applications

For each application deployed from your Nx monorepo:

1. Go to Monitors → New Monitor
2. Choose HTTP / HTTPS
3. Enter the deployed URL, e.g. https://web.example.com/api/health
4. Set interval to 1 minute
5. Configure expected response: status 200, body contains "status":"ok"
6. Save

Repeat for each app in your monorepo that serves external traffic.

Step 5: Track key metrics

For an Nx + NX Cloud setup, monitor:

| Metric | What it signals | |---|---| | NX Cloud endpoint uptime | Build slowdowns, DTE failures, cache misses | | App HTTP uptime | Deployment failures, runtime crashes | | App response time | Performance regressions from new builds | | TCP port (databases, caches) | Service layer failures below the app |

Vigilmon's response time history is particularly useful here: if a new build deployed via Nx introduces a performance regression, you'll see it as a spike in p95 response time on your Vigilmon charts — correlated with the deploy time.

Step 6: Integrate Vigilmon checks into your Nx CI pipeline

Add a post-deploy health check to your Nx CI configuration to verify deployments before marking a build as successful:

# .github/workflows/deploy.yml
jobs:
  deploy:
    steps:
      - name: Build and deploy
        run: npx nx run web:deploy

      - name: Wait for health check
        run: |
          for i in $(seq 1 30); do
            STATUS=$(curl -s -o /dev/null -w "%{http_code}" https://web.example.com/api/health)
            if [ "$STATUS" = "200" ]; then
              echo "Service healthy"
              exit 0
            fi
            echo "Attempt $i: status $STATUS, retrying..."
            sleep 5
          done
          echo "Service did not become healthy"
          exit 1

This pattern means a failed deployment that breaks the health endpoint will fail the CI run — keeping your Vigilmon monitors consistently green after successful builds.

Step 7: Configure alert channels

1. Go to Alert Channels → Add Channel
2. Choose Webhook for Slack or Discord
3. Paste your webhook URL
4. Assign the channel to:
   • Your NX Cloud endpoint monitor
   • All deployed application monitors
5. Set alert trigger: 1 failed check for immediate notification

For large monorepos with many deployed apps, use a dedicated #nx-build-alerts Slack channel so build-infrastructure alerts don't get lost in general engineering noise.

Step 8: Create a status page for your monorepo services

If your monorepo powers multiple public-facing services, a status page gives users and internal stakeholders visibility without needing to ask:

1. Go to Status Pages → New Status Page
2. Name it, e.g. "Platform Services"
3. Add monitors for each deployed application
4. (Optionally) add the NX Cloud monitor for internal build-health visibility
5. Publish the page

Share the URL in your engineering Slack and link it from your internal documentation.

Putting it all together

A complete NX Cloud + Vigilmon monitoring setup for an Nx monorepo:

nx.json
└─ NX Cloud access token configured

Nx monorepo apps:
├─ apps/web      → /api/health → HTTP monitor on https://web.example.com/api/health
├─ apps/api      → /health     → HTTP monitor on https://api.example.com/health
└─ apps/admin    → /health     → HTTP monitor on https://admin.example.com/health

Vigilmon monitors:
├─ NX Cloud:      https://cloud.nx.app             (1-min HTTP check)
├─ Web app:       https://web.example.com/api/health  (1-min HTTP check)
├─ API:           https://api.example.com/health       (1-min HTTP check)
└─ Admin:         https://admin.example.com/health     (1-min HTTP check)

Alert channel: Slack #nx-build-alerts
Status page:   https://status.vigilmon.online/your-platform

Conclusion

NX Cloud accelerates your Nx monorepo builds; Vigilmon ensures you know the moment that acceleration disappears or the resulting deployments stop serving traffic. By monitoring both the NX Cloud connectivity endpoint and each deployed application, you close the observability gap between "the build passed" and "the service is healthy." Set up takes under ten minutes and gives you multi-region external visibility, instant alerts, and a status page — all on Vigilmon's free tier.