How would you monitor the health of worker processes in a Node.js cluster in production?
Worker health in production is monitored using PM2's built-in monitoring dashboard, cluster lifecycle events (online, exit, disconnect), custom heartbeat mechanisms via IPC, and external APM tools like New Relic, Datadog, or Prometheus with Grafana.
Monitoring worker health is critical in production to detect crashes, memory leaks, and unresponsive processes. There are multiple layers of monitoring: built-in Node.js cluster events for basic health, PM2 for process management dashboards, and APM (Application Performance Monitoring) tools for deep observability.
- 1
PM2 — pm2 monit provides real-time CPU/memory per worker, auto-restart on memory threshold breach
- 2
Cluster lifecycle events — listen to online, exit, disconnect events on the cluster object
- 3
Custom heartbeat via IPC — workers send periodic pings; master kills unresponsive ones after a timeout
- 4
process.memoryUsage() — monitor heap usage per worker to detect memory leaks over time
- 5
Datadog / New Relic APM — instrument workers with agents for distributed tracing and alerting
- 6
Prometheus + Grafana — expose custom metrics per worker and aggregate via Prometheus scraping
Scenario Questions
0-2 years experience
- 1You have a small Node.js service using the cluster module with two workers. How would you instrument it so you can tell if a worker has died or become unresponsive?
- 2If a worker process exits unexpectedly, what steps would you take in code to restart it and log the event?
- 3What simple metric would you expose on a health endpoint to indicate the number of healthy workers?
2-5 years experience
- 1Your service runs 20 workers behind a load balancer, and you notice occasional latency spikes. How would you use monitoring to pinpoint whether a specific worker is underperforming or crashing?
- 2During a deployment you see the master process reporting 'worker died' messages, but the overall request success rate stays high. How would you investigate why the alerts are firing and decide if they’re false positives?
- 3Explain the trade‑offs between using process‑level heartbeats versus OS‑level metrics (CPU, memory) for detecting a hung worker.
5-8 years experience
- 1Design a production‑grade health‑checking system for a Node.js cluster that runs hundreds of workers across multiple hosts. What components would you include, and how would you ensure low‑overhead detection of stuck or dead workers?
- 2Your monitoring platform can ingest custom metrics but has a rate limit. How would you aggregate worker health data to stay within limits while still providing actionable alerts?
- 3If a worker process experiences a memory leak that only manifests after several hours, how would you detect it early and automate a graceful restart without dropping in‑flight requests?
8+ years experience
- 1At a company‑wide level you need to standardize health monitoring for all Node.js services using clusters. What architecture would you propose to centralize metrics, define SLAs, and handle versioned rollout of monitoring agents?
- 2Legacy services use a custom script to ping workers via IPC. How would you migrate them to a unified observability stack while minimizing risk and ensuring backward compatibility?
- 3Discuss the long‑term maintenance implications of embedding health‑check logic inside each service versus using an external sidecar or service mesh.
Follow-up Questions
- What would you do if a worker becomes CPU‑bound but doesn't crash?
- How would you avoid alert fatigue when workers restart frequently during deployments?
- Can you describe how you’d test your monitoring setup before shipping to production?