A long-running Node service hits an unhandled promise rejection in production. Should the process crash, as Node does by default, or should you install a handler that logs and keeps serving? How would you decide?

## Start from what the signal means An unhandled rejection is not "an error occurred". Errors occur constantly in a healthy service and are handled at their call sites. An unhandled rejection means an error occurred **on a path where nobody wrote a handler** — which is a much stronger statement. It tells you the code reached a state its author never considered, and it tells you nothing about what was left half-done. That is why the question is not really "crash or log". It is: can you characterise the state the process is in? If you cannot — and by construction you cannot, because you did not anticipate this path — then continued execution is unbounded risk. ## The case for crashing Node's default since v15 is `throw`: raise the rejection as an uncaught exception, print it, exit non-zero. For a stateless request-handling process supervised by an orchestrator, this is close to ideal: - The blast radius is bounded to the requests in flight on that instance. - Restart cost is seconds, and a fresh process has provably clean state. - The failure is loud, which is what gets it fixed. The preconditions are worth naming explicitly, because they are what make crashing safe: more than one instance behind a load balancer, a supervisor that restarts automatically, restart-loop protection with backoff, and no important state that lives only in this process's memory. ## The case against reflexive crashing Crashing is a poor answer when those preconditions fail. A single-instance job runner mid-way through a batch, a process holding an in-memory queue that has not been persisted, a desktop or CLI tool where exiting destroys the user's work — in those cases exiting *is* the data loss. The honest response there is not to install a swallow-all hook; it is to fix the architecture so the state is not exclusively in memory, and until then to make the hook's shutdown path do the persisting. There is also the restart-storm concern: if the rejection is triggered by a request pattern that every instance receives, crash-on-rejection turns a bug into a fleet-wide outage. That is a real risk, and it is an argument for rate-limiting restarts and for canary deploys — not an argument for continuing to serve from unknown state. ## The trap nobody expects ```js process.on('unhandledRejection', (reason) => { logger.error({ reason }, 'unhandled rejection'); }); ``` This looks like pure observability. It is not: Node's `throw` policy applies **only when no `unhandledRejection` listener is registered**. Adding this hook silently changes the service's crash policy. Six months later nobody remembers that the three-line logging improvement is why the service now runs indefinitely in corrupted states. The fix is to make the policy explicit inside the hook: ```js process.on('unhandledRejection', (reason) => { logger.fatal({ reason }, 'unhandled rejection — shutting down'); process.exitCode = 1; server.close(() => process.exit(1)); setTimeout(() => process.exit(1), 5000).unref(); // hard deadline }); ``` Now the hook adds context and a graceful drain without giving up fail-fast. Node also lets you state the policy at the process level with `--unhandled-rejections=<mode>`, whose modes include `throw`, `strict`, `warn`, `warn-with-error-code` and `none`; choosing anything other than the default should be a documented decision, not a copied flag. ## Keep the hook a detector, not a net The global hook is only useful if reaching it is rare and always means a bug. That requires the complementary discipline at every call site: - Anything you expect to fail is handled where it fails, with the context to retry or degrade. - Every deliberate fire-and-forget call carries its own `.catch()` that logs and moves on. - Lint rules flag promises that are neither awaited, returned, nor caught. If those are in place, an entry in the global hook is a page-worthy event. If they are not, the hook fills with routine noise, everyone stops looking at it, and you have neither observability nor safety. ## How to present the decision A strong answer states the default (crash), names the preconditions that make it safe (multiple instances, supervisor, no memory-only state), names the exceptions (single-instance stateful workers, user-facing tools), and — most tellingly — flags the listener-disables-the-crash trap, because that is the part teams discover the hard way. Framing it as "observability belongs in the hook, survival does not" keeps the two concerns from being conflated.