Diagnosing intermittent crashes with PM2

WHAT THIS TESTS Whether the candidate can keep a service up while genuinely diagnosing the failure, rather than masking crashes behind restarts.

A GOOD ANSWER COVERS PM2 is a process manager that improves availability and aids diagnosis. For availability, it automatically restarts a process that exits and can run the app in cluster mode with multiple worker instances across CPU cores, so a single worker crashing does not take the whole service offline and reloads can be zero-downtime. For diagnosis, pm2 logs aggregates stdout and stderr with timestamps, surfacing the stack traces and exit codes from crashes; pm2 monit and PM2 metrics show per-process CPU and memory in real time, which helps spot a memory leak (steadily climbing RSS before a crash) or event-loop stalls. The restart counter and uptime reveal how often and when crashes happen. You also wire up process-level handlers to log uncaughtException and unhandledRejection with full context before exiting, and ship logs and errors to a central system so intermittent failures can be correlated across instances.

COMMON WRONG ANSWERS Treating auto-restart as the solution and never finding the cause, which hides recurring leaks or bugs. Restarting manually and hoping it stops. Not capturing the crash stack trace. Ignoring memory growth trends that precede an out-of-memory kill.

LIKELY FOLLOW-UPS How do you detect a memory leak with PM2 plus heap snapshots? What is the difference between fork and cluster mode? How do you reload with zero downtime? How would you correlate crashes across instances?

ONE CONCRETE EXAMPLE pm2 monit shows one worker's memory climbing steadily over an hour until it crashes and PM2 restarts it, while the other clustered workers keep serving traffic. pm2 logs reveal an unhandledRejection from a leaked database connection. The team fixes the leak, and meanwhile cluster mode plus auto-restart keep the service available throughout the investigation.