How to Monitor Fnm Managed Services with Vigilmon

Fnm (Fast Node Manager) is a fast and simple Node.js version manager built with Rust. It resolves .node-version and .nvmrc files, switches Node.js versions in milliseconds, and works cross-platform without shell restarts. But when the Node.js services fnm manages go down, fnm itself won't tell you.

In this tutorial you'll add external uptime monitoring to services built and run with fnm-managed Node.js versions using Vigilmon — free tier, no credit card required.

Why monitor fnm managed services?

Fnm is used in local development, CI, and staging environments where teams want fast, automatic Node.js version switching without the overhead of a full runtime manager. Once those services are running, the standard failure modes apply:

• Silent version mismatches — fnm resolves the wrong Node.js version when .node-version is missing or malformed, and the service starts with an unexpected runtime
• Native module incompatibilities — a Node.js version change causes native addons to fail at runtime, crashing the process silently
• Process crashes without notification — the Node.js process exits and the port goes dark with no alert sent
• CI version drift — the CI runner's cached fnm install lags behind the pinned .node-version, causing subtle behavioral differences between local and production

Vigilmon monitors from outside your infrastructure, giving you an objective signal that is independent of what fnm or the host process thinks is running.

What you'll need

• A Node.js service started under a fnm-managed version that exposes an HTTP or TCP endpoint
• A free Vigilmon account

Step 1: Add a health endpoint to your Node.js service

Give Vigilmon something reliable to check. Add a /health route that exposes the Node.js version:

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

// Fastify
fastify.get('/health', async () => ({
  status: 'ok',
  node: process.version,
  uptime: process.uptime()
}));

Including process.version in the response makes it easy to confirm which Node.js version fnm actually resolved — useful when debugging version drift between local, CI, and production.

Step 2: Verify the fnm-resolved version on startup

Add a startup check to your entry point or start script to confirm fnm resolved the expected Node.js version before the service accepts traffic:

// startup-check.js
const { execSync } = require('child_process');
const fs = require('fs');

const expected = fs.readFileSync('.node-version', 'utf8').trim();
const actual = process.version.replace('v', '');

if (!actual.startsWith(expected.replace('v', ''))) {
  console.error(`ERROR: expected Node ${expected}, got ${process.version}. Run: fnm use`);
  process.exit(1);
}

// package.json
{
  "scripts": {
    "prestart": "node startup-check.js",
    "start": "node server.js"
  }
}

This prevents a misconfigured fnm environment from silently running the wrong Node.js version in production.

Step 3: Set up HTTP monitoring in Vigilmon

Once your service is running at a publicly reachable URL, point Vigilmon at the health endpoint:

1. Log in to vigilmon.online and go to Monitors → New Monitor
2. Choose HTTP / HTTPS
3. Set the URL to your 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

Vigilmon checks from multiple regions every minute. A timeout or non-200 response opens an incident immediately.

Step 4: Add TCP port monitoring for non-HTTP services

Fnm manages runtimes for any Node.js process — not just HTTP servers. Add a TCP monitor for any port your fnm-managed process binds:

1. Go to Monitors → New Monitor
2. Choose TCP Port
3. Enter your server hostname and port, e.g. worker.example.com / 3000
4. Save

If the Node.js process crashes or the port binding drops, Vigilmon fires an alert within a minute — regardless of what the process supervisor or PM2 reports.

Step 5: Track key metrics

| Metric | What it catches | |---|---| | HTTP response code | Application crash, bad deploy, native module failure | | HTTP response time | Performance regression from Node.js version change | | TCP port reachability | Process exit, fnm shim resolution failure | | Response body node field | Silent Node.js version mismatch in production |

Vigilmon stores response time history automatically. Set a threshold alert (e.g. alert if response time > 1.5 s) to detect performance regressions after a Node.js version upgrade.

Step 6: Add a heartbeat monitor to CI fnm setup steps

Fnm is used heavily in CI to pin Node.js versions for each workflow. When the fnm release server is unavailable or the requested version is not cached, CI hangs or fails — and deployments never happen. Add a Vigilmon heartbeat to your CI setup step:

1. In Vigilmon, go to New Monitor → Heartbeat
2. Name it CI Node Setup — main
3. Set the expected interval to your CI frequency (e.g. 1 hour)
4. Copy the ping URL

In your GitHub Actions workflow:

- name: Set up Node.js with fnm
  run: |
    curl -fsSL https://fnm.vercel.app/install | bash
    export PATH="$HOME/.local/share/fnm:$PATH"
    eval "$(fnm env)"
    fnm use --install-if-missing
    node --version

- name: Build and deploy
  run: npm run build && npm run deploy

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

If fnm fails to install or the build breaks, no ping is sent and Vigilmon alerts after the grace period.

Step 7: Configure alert channels

1. Go to Alert Channels → Add Channel
2. Choose Email or Webhook (Slack, Discord, PagerDuty)
3. Assign the channel to your HTTP and TCP monitors
4. Set the alert trigger to 1 failed check for immediate notification

When a service goes down:

🔴 DOWN: api.example.com/health
Duration: 3 minutes
Last response: timeout

When it recovers:

✅ RECOVERED: api.example.com/health
Downtime: 3 minutes

Step 8: Create a status page for your Node.js services

If multiple Node.js services use fnm-pinned versions, a status page surfaces all of them in one view:

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

Team members can check service health before reporting a bug, and you avoid being paged for self-inflicted outages caused by Node.js version changes.

Conclusion

Fnm ensures every developer and CI runner uses exactly the right Node.js version. Vigilmon ensures those Node.js services are actually serving healthy traffic. Together they close both the "wrong version" and the "service is down" gaps. Set up a /health endpoint, create a one-minute Vigilmon HTTP monitor, and add heartbeat monitoring to your CI fnm setup step — you'll have full coverage in under ten minutes.

Get started free at vigilmon.online.