What happens when a worker process crashes in a Node.js cluster?
When a worker crashes, the master process receives an 'exit' event. You can listen to this event and call cluster.fork() to automatically respawn a new worker, ensuring high availability of the application.
Worker crashes are a natural occurrence in production environments. The Cluster module provides the 'exit' event on the cluster object that fires whenever a worker dies. You must explicitly handle this event and fork a new worker — Node.js does NOT automatically restart crashed workers without your intervention.
- 1
worker — the Worker object that exited
- 2
code — the exit code (0 = clean exit, non-zero = error)
- 3
signal — the signal that killed the process (e.g., SIGKILL)
- 4
worker.exitedAfterDisconnect — true if intentionally disconnected, false if crashed
Scenario Questions
0-2 years experience
- 1If a worker in a Node.js cluster crashes, what does the master process do by default?
- 2How would you ensure that a crashed worker is automatically replaced so the server keeps handling requests?
- 3What happens to in‑flight requests when a worker process exits unexpectedly?
2-5 years experience
- 1We observed occasional 502 errors after a worker crash in our cluster. Walk me through how you would debug the root cause.
- 2Suppose you need to add custom cleanup logic when a worker dies. How would you modify the cluster code to handle that?
- 3If you wanted to limit the number of worker restarts within a minute to avoid a crash loop, how would you implement that?
5-8 years experience
- 1Design a strategy for graceful shutdown and restart of workers in a high‑traffic Node.js service when a worker crashes, ensuring minimal request loss.
- 2Discuss the trade‑offs between using the built‑in cluster restart behavior versus implementing your own process manager (e.g., PM2) for handling worker crashes at scale.
- 3How would you monitor and alert on worker crash patterns across multiple servers in a distributed deployment?
8+ years experience
- 1Our platform runs thousands of Node.js clusters across many services. How would you architect a unified crash‑handling and recovery framework that works across teams while preserving service level objectives?
- 2Explain how you would migrate a legacy monolithic Node.js app to a clustered architecture, addressing concerns about worker crash handling, state consistency, and operational tooling.
- 3What policies would you set for automated worker restarts, back‑off, and circuit‑breaker integration in a multi‑tenant environment, and why?
Follow-up Questions
- What would you log to help diagnose frequent worker crashes?
- How would you test your crash‑handling logic in CI?
- Can you describe how you’d integrate this with a health‑check endpoint?