After a release, one page in a web app becomes unresponsive: the tab pins a CPU core, no error appears in the console, and log lines inside setTimeout callbacks never print. How would you establish that a microtask loop is starving the event loop, and distinguish it from a plain blocking synchronous loop?

## Why the symptom alone does not identify the cause A pinned core plus a dead UI is the shared signature of several distinct failures on a single-threaded runtime: - a synchronous loop or a very expensive computation that never returns; - a microtask loop that keeps the checkpoint from ever finishing; - runaway synchronous work re-triggered by a handler, so each turn is short but they never stop. They demand different fixes, and only the third is even visible as separate tasks. Guessing wastes the one thing you have — the reproduction. ## Confirm the task queue is blocked, not just slow Start with the cheapest signal. Add a heartbeat before the suspect path: ```js let last = performance.now(); setInterval(() => { const now = performance.now(); console.log('heartbeat late by', Math.round(now - last - 250), 'ms'); last = now; }, 250); ``` If the heartbeat stops entirely at the moment the page freezes, the **task queue** is starved — no timer callback is being dispatched at all. If it keeps printing with growing lateness, you have contention rather than starvation, and the hunt is for something long but finite. This one line separates "nothing runs" from "everything is late", which is the first fork in the tree. ## Read the shape in a profile Record a performance profile across the freeze. The sampling profiler is not running on the blocked thread, so it still collects while the page is unresponsive. What you are reading for is shape: - **Blocking synchronous work** — one continuous frame. The stack is stable across samples, often deep, and the same function sits at the top for the whole span. There is exactly one task. - **Microtask starvation** — one task that never ends, containing an enormous run of very short, near-identical callbacks. The stack is *shallow*, because each microtask returns before the next begins, and it is the same shallow stack over and over. There are no gaps for rendering, no input events dispatched, no other tasks anywhere in the span. That shallow-and-repeating signature is the tell. It also explains why the failure produces no useful error: no frame is long, no recursion overflows the stack, nothing throws. ## Confirm in the debugger Pause execution during the freeze. In the blocking case you break somewhere inside the long-running function, and the call stack shows the path that called it. In the starvation case you break in a promise reaction or a `queueMicrotask` callback with almost nothing beneath it, and the debugger will typically show the async cause that scheduled it. Resume and pause again: landing repeatedly in the same short callback, with a fresh shallow stack each time, is confirmation. Stepping is also diagnostic. Stepping out of a starving microtask returns immediately — and the next microtask begins — rather than continuing inside a long function body. ## Find the offender in the diff Once the mechanism is established, the search is narrow. Look through the release for any code that schedules its own continuation without a task boundary: - `queueMicrotask` called from inside a `queueMicrotask` callback; - `Promise.resolve().then(sameFunction)` recursion; - `while (!cond) await Promise.resolve()` or similar spin-waits, especially where `cond` is set by a timer or an event handler — those can never terminate, because the spin blocks the very callback that would flip the flag; - a retry that resolves synchronously on failure, so every attempt costs a microtask and no elapsed time; - a library update that changed a scheduler from a timer to a microtask. A text search for `queueMicrotask` and for `.then(` inside the functions the profile named usually finishes the job in minutes once you know what you are looking for. ## Why a plain reproduction is often faster than tooling Because the freeze is deterministic, a bisect over the release — or over feature flags — costs a handful of reloads and points at a commit. Use tooling to establish the *class* of failure, and bisection to find the line. Trying to bisect without knowing the class leads teams to "optimise" a function that was never the problem. ## Prevent the recurrence Ship the heartbeat, or an equivalent responsiveness probe, as permanent instrumentation in development builds — starvation is trivially detectable the moment it appears and nearly invisible afterwards. Make it a review rule that any self-rescheduling loop names the queue it resumes on, and that unbounded loops yield to a task with an explicit time budget. And treat spin-waiting on a flag as a defect on sight: if another callback sets the condition, await a promise that callback resolves instead of polling for it.