If you could only watch one metric to catch a Node process going bad before users notice, what would it be? And how do you measure it properly?
A strong answer picks event-loop delay as the metric that moves first when a Node process goes bad, and measures it as a histogram instead of an average
I'd say event-loop lag, or event-loop delay, same thing. Node runs your JavaScript on a single thread, so if anything blocks the event loop, every request gets delayed, and the thing is CPU and memory can still look totally fine while that's happening. So watching the lag tells you when the loop is falling behind. You measure it with perf_hooks, there's a monitorEventLoopDelay function that records the delay into a histogram. If the lag is rising it means the loop can't get to events promptly, usually because of synchronous or CPU-heavy work somewhere. You'd set an alert threshold, maybe tens of milliseconds or something like that, and investigate when it crosses. The usual fix is moving the blocking work off the main thread, into a worker thread or an async operation. It catches problems the CPU and memory graphs just miss, so it's the one to watch first.