A Node.js process can stay alive while the event loop is blocked, the database pool is exhausted, or one worker serves stale code. Node.js uptime monitoring must combine external API checks with event-loop, memory, process, and dependency signals.
Monitor the Node.js failure surface
| Layer | Failure mode | Signal |
|---|---|---|
| Public API | Timeout, wrong JSON, 5xx | External request with body validation |
| Event loop | CPU work or sync I/O stalls requests | Event-loop delay and utilization |
| Process | Crash, OOM, restart loop | Process count, restart count, RSS and heap |
| Database or cache | Pool exhaustion or slow dependency | Readiness plus pool wait metrics |
| Worker threads or child processes | Partial capacity loss | Expected versus live workers |
| Queue consumers | Jobs age while API stays healthy | Oldest-job age and completion heartbeat |
Design liveness and readiness
Keep liveness cheap: it should prove that the process can answer. Readiness may test the primary database or another dependency required for normal traffic and should return 503 when the instance must leave rotation. Do not call every third-party API from readiness; monitor optional dependencies independently.
Check a real endpoint using the same method, authentication, headers, and response contract as clients. A JSON API that returns 200 with an error object is not healthy. See API uptime monitoring and response-body validation.
Watch the event loop and memory
Node's official perf_hooks documentation provides monitorEventLoopDelay() and eventLoopUtilization(). Track delay percentiles alongside CPU: high event-loop delay with moderate CPU often points to synchronous work, long garbage-collection pauses, or an overloaded native dependency.
Track RSS, heap used, heap limit, garbage-collection duration, active handles, and restart count. Node's diagnostic report can capture JavaScript and native stacks, heap data, libuv handles, and resource usage on fatal errors or a signal. Store reports securely because they can contain application context.
Make deploys observable
- expose a non-secret release ID in the health response;
- stop accepting traffic before shutdown and allow in-flight requests to finish;
- verify every cluster worker or container runs the new release;
- run a post-deploy request against a data-backed endpoint;
- compare error rate, p95 latency, event-loop delay, and restarts to the previous release.
For self-hosted clusters, monitor the reverse proxy and each process group. For serverless Node.js, prioritize function errors, duration, concurrency, cold starts, and downstream connection pressure instead of process uptime.
Node.js monitoring checklist
- Real API request validated externally
- Liveness is cheap and readiness covers critical dependencies
- Event-loop delay and utilization tracked
- RSS, heap, garbage collection, restarts, and worker count tracked
- Queue age and scheduled-job completion monitored
- Graceful shutdown tested
- Release ID visible in health and alerts
- Diagnostic reports enabled and stored securely
Webalert supplies external HTTP, JSON content, response-time, TLS, and heartbeat checks. Start monitoring, then correlate those checks with Node.js runtime metrics and memory-leak diagnostics.