Let It Crash: Best Practices for Handling Node.js Errors on Shutdown

Summary

Node.js applications can lose visibility into failures and experience downtime when processes crash or shut down without useful logging and recovery practices. The post presents lessons from consulting and a talk on the Node.js process lifecycle, focusing on graceful shutdown, error visibility, and fast restart after catastrophic errors. It recommends keeping startup lean by prebuilding data or compiling assets, then contrasts process.exit(), which accepts an exit code, with process.abort(), which terminates immediately and may generate a core dump for llnode-based postmortem debugging. It also explains beforeExit and exit, including their differing asynchronous-work behavior, and introduces SIGTERM and SIGINT as operating-system signals that applications can handle. The intended result is a restartable process strategy that reduces downtime, while preserving evidence needed to investigate crashes.

Takeaways

1. 1

   Keep Node.js startup lean by prebuilding data or compiling assets outside the startup process, allowing a crashed process to restart with less downtime.

2. 2

   process.exit() ends a process with an exit code, while process.abort() terminates immediately and may create a core dump that can support postmortem debugging with llnode.

3. 3

   beforeExit can run asynchronous work before the event loop finishes, whereas exit occurs after the event loop has terminated and cannot perform asynchronous work; SIGTERM and SIGINT are also handleable shutdown signals.