What blocks the loop: CPU work and sync calls

A health-check endpoint that does nothing but return 200 OK starts timing out. Nothing touches it; its code is two lines. The real cause is three routes away: a reporting endpoint calls JSON.parse on a 40 MB payload, and for the ~800 ms that parse runs, the single loop thread is busy and every other request — including the trivial health check — sits frozen in the queue. Nobody wrote a slow health check. Someone wrote one slow synchronous line, and cooperative concurrency spread the pain to the whole process.

One slow callback stalls everyone

The last lesson’s payoff and price are the same fact: callbacks run to completion with no preemption. As long as everything yields quickly — await on I/O, return fast — thousands of connections interleave smoothly. But the moment one callback does synchronous work that takes real time, the loop cannot advance to the poll phase, cannot run any other I/O callback, cannot fire any timer. The cost is not “this request is slow.” It is head-of-line blocking for the entire process: every concurrent request pays the full duration, because they are all waiting behind the one callback hogging the thread.

This is the defining failure mode of the model. In a thread-per-connection server, one slow request slows that thread; here, one slow synchronous span slows all of them.

The usual culprits

Blocking work comes in two flavors: synchronous APIs that do I/O on the loop thread, and CPU-bound computation that simply takes too long between yields.

• Sync I/O APIs — fs.readFileSync, fs.writeFileSync, child_process.execSync. These do the I/O on the loop thread and can stall it for hundreds of milliseconds (a sync read of a large file was measured around 1200 ms). The async twins (fs.promises.readFile) hand the work off and let the loop continue.
• Big JSON.parse / JSON.stringify — parsing or serializing a multi-megabyte payload is pure CPU on the loop thread; a large parse was measured around 800 ms of frozen loop.
• Synchronous crypto — bcrypt.hashSync at a realistic cost factor blocks roughly 200–400 ms per call; under login load that single line collapses throughput. Hashing, crypto.pbkdf2Sync, large gzipSync.
• Catastrophic regex (ReDoS) — a pattern with nested quantifiers like /A(B|C+)+D/ against a crafted string can backtrack exponentially; one documented case spent ~3.7 seconds of pure CPU on a single input. Because it is on the loop thread, an attacker can freeze the whole server with one request — a denial of service.

Event-loop lag: seeing it before users do

You do not need users to report timeouts to find blocking. The direct signal is event-loop lag (a.k.a. event-loop delay): schedule a timer for t ms and measure how late it actually fires. If a setTimeout(fn, 0) consistently runs 200 ms late, the loop was busy 200 ms — that lateness is the blocking, quantified. Node exposes perf_hooks.monitorEventLoopDelay() for a histogram (p50/p99 of lag), and tools like clinic.js surface it; a common production alert threshold is around 100 ms of lag.

The mental test

Before any line runs on the loop thread, the senior reflex is one question: is this bounded and fast, or could it run for tens of milliseconds on a big input? Reading a 2 KB config sync at startup is fine. Parsing arbitrary user-supplied JSON of unknown size, hashing a password, or matching a user-controlled string against a backtracking regex on the request path is not — those belong off the loop, which is the next lesson.