How to monitor Node.js apps

What can go wrong with Node.js apps

• Event loop blocked. One synchronous operation (a large JSON.parse, a sync file read, a CPU-heavy loop, a catastrophic regex) stalls every request on that process, so latency jumps for all routes at once.
• Heap exhaustion. A leak grows the heap until V8 aborts with FATAL ERROR: … JavaScript heap out of memory. The process manager restarts it and the cycle repeats.
• Unhandled promise rejections. Since Node 15, an unhandled rejection crashes the process by default. In-flight requests on that process fail.
• Restart loops. pm2, systemd or Kubernetes restart the crashed process so quickly that uptime checks rarely catch it; the restart counter does.
• Slow dependencies. A slow database query or third-party API holds connections from a small pool, and requests queue behind them.

The signals that matter, with alert thresholds

Thresholds are starting points. Tune them after a week of data: an alert nobody acts on should be raised or removed.

How to check Node.js apps by hand

curl -fsS -o /dev/null -w '%{http_code} %{time_total}s\n' http://127.0.0.1:3000/health

node -p "require('v8').getHeapStatistics().heap_size_limit / 1048576"

ps -o pid,rss,etime,args -C node

pm2 list
pm2 describe my-app | grep -E 'restarts|memory'

How to watch Node.js apps with Vigil

1. In New monitor create an API check on /health with an assertion such as json status == ok, and an Uptime monitor on the public site.
2. Add the host under Servers and run the one-line installer it shows (curl -fsSL https://puzaricloud.in/install-server-agent.sh | sh -s -- --token <token>). The agent is one Python file with no dependencies; CPU, memory, disk, inode and load rules start working with the first report. Add node (or your unit name) to the processes that must be running, and ship the app's log files or journal unit.
3. Add tracing: download /vigil-apm.js and call require('./vigil-apm').init({ service: 'web' }) first thing at start-up. It instruments http(s), fetch, pg, mysql2 and ioredis and sends spans to the agent on 127.0.0.1:9111. Or use the OpenTelemetry Node SDK with the OTLP endpoint (quick start).
4. You get routes with latency histograms, Apdex, slow queries ranked by total time, slow outbound calls, N+1 detection and the impact of each deploy.
5. Create a project under Errors and use its DSN with @sentry/node: uncaught exceptions and rejections arrive grouped, with alerts on new issues and regressions.

Every alert goes to the channels you pick: email, Slack, Telegram, Discord, Microsoft Teams, Pushover, webhooks or on-call paging. Failures are confirmed by a second check before anyone is woken up.

Node.js apps monitoring FAQ