JavaScript Event Loop: Microtasks vs Macrotasks, Predicting Output Order, and Starving the Loop

A teammate ships a "harmless" refactor: an export endpoint now builds a 200k-row report with a chain of async helpers instead of a plain loop. Nothing is awaited on the network, everything is in memory. Within an hour the health check starts timing out, p99 latency on unrelated endpoints jumps from 40 ms to 6 seconds, and the Kubernetes liveness probe restarts the pod. CPU looks busy but not pegged. The code has no infinite loop, no deadlock, and every function returns.

The culprit is the event loop. The refactor turned one long synchronous task into hundreds of thousands of chained microtasks, and in JavaScript microtasks always run before the loop is allowed to look at timers, sockets or the next HTTP request. If you understand exactly what runs when, bugs like this become obvious and output-order interview puzzles become boring. Here is the model I use.

One Thread, One Call Stack

JavaScript runs your code on a single thread with a single call stack. When you call a function, a frame is pushed; when it returns, the frame is popped. While that stack is non-empty, nothing else can run: no timer callback, no promise reaction, no click handler, no incoming request in Node. Every "concurrent" thing in JavaScript is really a queue of callbacks waiting for the stack to be empty.

The host (the browser or Node's libuv) does the actual waiting for timers, sockets and files on other threads or in the kernel. When something finishes, the host does not interrupt your code. It puts a callback into a queue. The event loop is just the policy that decides which queue gets served next once the stack is empty.

There are two families of queues that matter:

• Macrotasks (the spec just calls them tasks): setTimeout, setInterval, setImmediate (Node), I/O callbacks, MessageChannel messages, UI events. The loop takes one of these per turn.
• Microtasks: promise reactions (.then, .catch, .finally, and the continuation after await), queueMicrotask, and MutationObserver callbacks in browsers. After every macrotask, and after the initial script, the loop drains all of them, including microtasks queued while draining.

Node adds one more queue in front: process.nextTick callbacks, which are drained before promise microtasks.

How the Loop Picks the Next Callback

This is the whole algorithm, simplified enough to predict output and accurate enough to debug production:

The key asymmetry is in steps C and D versus step F. Microtasks are drained until the queue is empty. Macrotasks are taken one at a time, with a full microtask drain after each. Browsers get a chance to render only between macrotasks, never in the middle of a microtask drain.

In Node, step F is more detailed because libuv cycles through phases (timers, pending callbacks, poll for I/O, check for setImmediate, close callbacks), but since Node 11 the rule that matters matches browsers: after each individual timer or immediate callback, Node drains nextTick and then the microtask queue.

Predicting Output Order

With that model, the classic puzzles are mechanical. Walk the script top to bottom, write sync output immediately, and put every callback in its queue.

console.log('A');

setTimeout(() => console.log('B'), 0);

Promise.resolve().then(() => console.log('C'));

queueMicrotask(() => console.log('D'));

console.log('E');

// Output: A E C D B

A and E are synchronous. C and D are microtasks, queued in that order, so they run in that order as soon as the script finishes. B is a macrotask and has to wait for the microtask queue to be empty, even with a delay of 0 (Node clamps it to 1 ms anyway, and browsers clamp deeply nested timers to at least 4 ms).

async/await is just promises with nicer syntax. The body of an async function runs synchronously until the first await. Everything after the await is scheduled as a microtask once the awaited value settles:

async function load() {
  console.log(1);
  await null;            // everything below becomes a microtask
  console.log(2);
}

console.log(0);
load();
Promise.resolve().then(() => console.log(3));
console.log(4);

// Output: 0 1 4 2 3

1 prints synchronously inside load(). await null wraps null in a resolved promise and queues the continuation. Then .then queues 3. 4 prints, the stack empties, and the microtasks run in FIFO order: 2, then 3. Before V8 7.2 an await on a native promise took three microtask ticks instead of one, so very old Node versions could print 3 before 2. If code correctness depends on that kind of tick counting, the code is wrong, not the engine.

The third rule people miss: microtasks queued inside a macrotask run before the next macrotask.

setTimeout(() => {
  console.log('t1');
  Promise.resolve().then(() => console.log('p1'));
}, 0);

setTimeout(() => console.log('t2'), 0);

// Output (Node 11+ and browsers): t1 p1 t2

Node versions before 11 ran all expired timers first and drained microtasks afterwards, printing t1 t2 p1. That changed to match browsers, and it is one more reason to never write logic that depends on how many timers fire per phase.

Finally, Node's own queues:

// main.cjs (CommonJS)
Promise.resolve().then(() => console.log('promise'));
process.nextTick(() => console.log('nextTick'));
setImmediate(() => console.log('immediate'));
setTimeout(() => console.log('timeout'), 0);

// Typical output: nextTick promise timeout immediate
// (timeout vs immediate order is NOT guaranteed in the main module)

nextTick beats promises because Node drains the tick queue first. setTimeout(fn, 0) versus setImmediate from the main module depends on how long process startup took relative to the 1 ms timer threshold, so it can flip between runs. Inside an I/O callback, setImmediate always fires first because the check phase comes right after poll. Also note: in an ES module, the top-level code itself runs as part of a promise job, so the promise vs nextTick order you observe there can differ from CommonJS. Another reason not to rely on it.

Starving the Loop

Because the microtask queue is drained until empty, a microtask that keeps scheduling microtasks blocks the loop forever, even though each individual callback is tiny:

// This never lets the timer fire: the microtask queue is never empty.
setTimeout(() => console.log('you will never see me'), 0);

function spin() {
  Promise.resolve().then(spin);
}
spin();

The call stack never grows, so you do not get a RangeError: Maximum call stack size exceeded. You just get a frozen tab or a Node process that stops answering requests while CPU sits at 100% on one core. Recursive process.nextTick does the same thing, even more aggressively, because it starves promises too.

The production incident from the intro is the softer version of this. Each await on an already-resolved value costs one microtask. A loop of 200k awaited helpers is 200k+ microtasks drained back to back, and from the event loop's point of view that is one enormous uninterruptible block. The fix is not "add more await". This does nothing for fairness:

// Looks like yielding, but is NOT: await on a resolved promise is a microtask,
// so the loop never reaches the timers or poll phase.
for (const row of hugeArray) {
  transform(row);
  await Promise.resolve();
}

To let the rest of the world run, you must yield a macrotask: setImmediate in Node, setTimeout(0) or MessageChannel in browsers, or scheduler.yield() where it is supported (Chromium-based browsers today).

Implementation: Time-Sliced Processing

The pattern I reach for is time slicing: do work until a budget is spent, then yield a macrotask so the loop can serve timers, I/O and requests, then continue. The clock is injectable so the behaviour is testable without real timing.

const { setImmediate: yieldToLoop } = require('node:timers/promises');

/**
 * Process a large array without blocking the event loop.
 * Runs `fn` on items until `budgetMs` is spent, then yields a macrotask
 * so timers, I/O callbacks and incoming requests get a turn.
 */
async function processInChunks(items, fn, { budgetMs = 10, now = () => performance.now() } = {}) {
  const results = [];
  let sliceStart = now();

  for (let i = 0; i < items.length; i++) {
    results.push(fn(items[i], i));

    if (now() - sliceStart >= budgetMs) {
      await yieldToLoop();   // a real macrotask, not a microtask
      sliceStart = now();
    }
  }

  return results;
}

module.exports = { processInChunks };

A budget of 5 to 15 ms per slice is a good starting point for a Node API server; it keeps per-request latency bounded while still doing real work per slice. In browsers aim for well under 16 ms so you do not drop frames, and consider moving truly heavy work to a Worker instead, where it cannot block the UI at all.

For CPU-bound jobs that take seconds, slicing is a band-aid. Use worker_threads in Node or a Web Worker in the browser, or push the job to a queue. Slicing shines for the middle ground: work that takes 50 to 500 ms and must stay on the main thread because it touches main-thread state.

Testing Event Loop Behaviour

You can test ordering with the built-in node:test runner. Record events into an array and assert on the sequence after giving the loop a real macrotask to finish. The second test proves that processInChunks really yields: a timer scheduled before the work must fire in the middle of the work, not after it. A fake clock makes the slice boundaries deterministic.

// event-loop.test.cjs  ->  node --test
const { test } = require('node:test');
const assert = require('node:assert/strict');
const { processInChunks } = require('./process-in-chunks.cjs');

const tick = () => new Promise((resolve) => setTimeout(resolve, 5));

test('microtasks drain before the next timer', async () => {
  const log = [];
  setTimeout(() => log.push('timeout'), 0);
  Promise.resolve().then(() => log.push('promise'));
  queueMicrotask(() => log.push('microtask'));
  log.push('sync');

  await tick();
  assert.deepEqual(log, ['sync', 'promise', 'microtask', 'timeout']);
});

test('processInChunks lets a timer run in the middle of the work', async () => {
  const log = [];
  setTimeout(() => log.push('timer'), 0);

  let fakeTime = 0;
  const now = () => fakeTime;
  const items = Array.from({ length: 6 }, (_, i) => i);

  const out = await processInChunks(items, (x) => {
    fakeTime += 5;            // pretend each item costs 5 ms
    log.push(`item${x}`);
    return x * 2;
  }, { budgetMs: 10, now });

  assert.deepEqual(out, [0, 2, 4, 6, 8, 10]);
  const timerAt = log.indexOf('timer');
  assert.ok(timerAt > 0 && timerAt < log.length - 1, `timer ran at ${timerAt}`);
});

If someone replaces yieldToLoop() with await Promise.resolve(), the second test fails, because the timer would only run after all items are processed. That is exactly the regression you want caught in CI rather than in production.

Common Pitfalls

• Assuming setTimeout(fn, 0) means "now". It means "after the current task, after all microtasks, and after at least 1 ms (4 ms when nested in browsers)". In an inactive browser tab it can be throttled to once per second or worse.
• Using await as a yield point. Awaiting a resolved promise, a sync function, or null is a microtask. It never lets timers, I/O or rendering run.
• Recursive process.nextTick or promise chains for "async recursion". They starve I/O. Use setImmediate for recursion that should be fair.
• Expecting async functions to run in the background. The body runs synchronously until the first await. An async function with a CPU-heavy loop and no await blocks just as hard as a normal function.
• Relying on cross-queue order like setTimeout vs setImmediate, or nextTick vs promises across module types. Express the dependency explicitly with await or callbacks instead.
• Unhandled rejections in microtasks. A rejected promise without a handler surfaces as unhandledRejection, which crashes Node by default since v15. Microtask scheduling does not make errors disappear.
• Measuring the wrong thing. Event loop lag is visible with perf_hooks.monitorEventLoopDelay(). If p99 delay is in the hundreds of milliseconds, look for long synchronous work or long microtask chains before blaming the database.

When to Care and When Not To

Care about the details when:

• a Node service shows latency spikes on cheap endpoints while one expensive endpoint is running;
• you write libraries that schedule callbacks (emitters, caches, stream adapters) and need a consistent "always async" contract (queueMicrotask is the right tool for that);
• you process large in-memory datasets on the main thread, in Node or in the browser;
• you debug flaky tests that pass or fail depending on timer timing.

Do not over-engineer when:

• the work is I/O-bound and naturally awaits the network or disk; the loop is already free while waiting;
• the job is truly CPU-heavy; move it to a worker or a queue instead of tuning slice sizes;
• you are tempted to depend on exact tick counts. Write code whose correctness holds for any interleaving and use the event-loop model only to reason about latency and fairness.

The short version to keep in your head: sync code first, then all microtasks, then one macrotask, repeat. If something can schedule work faster than it finishes, it will starve everything behind it.