Event-Loop Lag: One Callback, Everybody Waits

A Node process handles concurrency by interleaving, not by parallelism: the event loop takes one ready callback, runs it to completion, and only then considers the next. While a callback runs, nothing else in that process progresses — not other requests, not timers, not I/O completions that have already arrived.

This makes CPU-heavy work uniquely damaging in a way that is easy to miss. In a thread-per-request server, a request that burns 200ms of CPU makes *that* request slow and competes with others for cores. In an event loop, that same 200ms is added to the waiting time of every callback already queued behind it. Ten concurrent requests, one of which does a 200ms synchronous parse, means the other nine each wait up to 200ms extra for work that has nothing to do with parsing.

The observable consequence is a system that degrades globally from a local cause. /health — which does nothing but return 200 — becomes slow, which is the clearest possible signal that the problem is not in any handler, and is also how these incidents often escalate: the load balancer removes healthy instances because their health checks timed out behind someone else's JSON.

Event-loop lag has a clean definition: schedule a timer for N milliseconds, measure how late it actually fires, and the excess is how long the loop was busy with something else. It requires no knowledge of what the blocking work was, which is exactly what makes it a good detector — it catches every cause of blocking, including ones you have not thought of.

Publish it as a histogram, not a mean. Lag is bursty by nature: a process can be perfectly responsive for 59 seconds and blocked for one, and an average over that minute looks fine. p99 lag is the number that corresponds to user-visible damage, in the same way and for the same reason as Percentiles: Which One, and How Many Users Is That? generally.

Modern Node exposes this natively via perf_hooks.monitorEventLoopDelay, which samples with less overhead than a naive timer loop and gives you percentiles directly. Either way, the metric belongs on the default dashboard for every Node service — it is cheap, it is unambiguous, and it is the single fastest way to distinguish "our dependency is slow" from "we are blocking our own loop".

Once lag is confirmed, a CPU profile identifies which callback is holding the loop (Self Time, Total Time, and Where the CPU Went). The fixes fall into four families, and they differ mainly in how much of the problem they actually remove versus relocate.

Moving work to a worker thread or a separate process genuinely removes it from the loop, at the cost of serialization across the boundary and a more complex deployment. Chunking — breaking a long synchronous computation into pieces that yield between them — keeps the work in-process and bounds the maximum block, but total latency for that request gets slightly worse and the code becomes harder to follow. Streaming replaces "parse 40MB then act" with incremental processing, which is usually the best answer for the specific case of large payloads. And sometimes the honest fix is upstream: an endpoint that needs to parse 40MB probably should not have been handed 40MB (Large Requests and Documented Limits).

The trap worth naming is async as a supposed fix. Marking a function async does not move CPU work off the loop; a synchronous 180ms computation inside an async function blocks exactly as long as it did before. await yields only at genuine asynchronous boundaries, so an await on an already-resolved promise buys nothing. This misunderstanding is common enough that it is worth checking explicitly before accepting "we made it async" as a resolution.