The Node.js Event Loop

The event loop is the mechanism that makes Node's whole concurrency story work: a loop, driven by libuv, that decides which piece of your pending JavaScript runs next. It's the thing that lets a single-threaded language handle thousands of concurrent connections - and the thing that turns one careless synchronous function into an outage.

How Node.js Works covers the broader V8-plus-libuv picture; this page goes one level deeper into the loop itself - its phases, its scheduling rules, and the assumptions that make it fast when respected and dangerous when ignored. Treat this as the conceptual anchor for the section: the hands-on examples in Event Loop Basics and the phase-by-phase and microtask deep dives that follow build on the model described here.

Summary

• The event loop is a fixed cycle of phases that libuv runs repeatedly, each phase responsible for one category of pending callback, with the call stack required to be empty before the loop advances.
• Insight: Almost every "why did this run before that?" or "why did my API stall?" question in Node traces back to how this cycle actually orders work - guessing gets you the wrong answer more often than not.
• Key Concepts: call stack, run-to-completion, phase, macrotask, microtask, cooperative scheduling.
• When to Use This Model: Diagnosing ordering bugs, reasoning about latency under load, deciding whether work belongs on the main thread, and reading the more detailed phase/microtask pages with the right frame already in place.
• Limitations/Trade-offs: The loop guarantees relative ordering, not exact timing - and it's cooperative, meaning it trusts every callback to finish quickly. It has no way to preempt a callback that doesn't.
• Related Topics: libuv phases, microtasks vs. macrotasks, timers and scheduling, event-loop blockage detection.

Foundations

JavaScript in Node follows run-to-completion: once a function starts executing, it runs until it returns, and nothing else - no other callback, no I/O completion, nothing - can interrupt it. The event loop's entire job is deciding what runs next, and it only gets to make that decision when the call stack is completely empty.

console.log('a');
setTimeout(() => console.log('b'), 0);
console.log('c');
// a, c, b - "b" cannot run until the synchronous code above it finishes

A useful mental model: picture a night-shift security guard making fixed rounds through a building. Each round visits the same stations in the same order - check the timers on the front door, clear the mailroom, listen at the monitors for new activity, sweep for anything flagged urgent, lock up anything closing - then the guard starts the round again from the top. The guard never does two stations at once, and never skips ahead; if something urgent happens between rounds, it waits for the guard to reach that station. That fixed, repeating circuit is the event loop - each "station" is a phase, and the guard is the single JavaScript thread executing whatever that phase hands it.

The loop isn't optional infrastructure sitting beside your code - it's what keeps the Node process alive at all. A process exits once there's nothing left to do: no pending timers, no open server sockets, no queued I/O. Every server.listen() or open handle is effectively a reason for the guard to keep making rounds; call .unref() on a handle to tell the loop "don't stay alive just for this."

Mechanics & Interactions

Each pass through the loop visits the same phases in the same fixed order:

┌───────────────┐
│   timers      │  setTimeout / setInterval callbacks whose time has passed
├───────────────┤
│ pending cbs   │  some system-level callbacks deferred from the previous pass
├───────────────┤
│ idle, prepare │  internal use only
├───────────────┤
│   poll        │  retrieve new I/O events; run I/O callbacks (most work happens here)
├───────────────┤
│   check       │  setImmediate callbacks
├───────────────┤
│ close cbs     │  e.g. socket.on('close', ...)
└───────────────┘
        │
        └──────────── back to timers, forever (while work remains)

That's the skeleton - libuv Phases covers what actually happens inside each one, including the poll phase's blocking behavior and how it decides when to move on. What matters at this level is the shape: it's a fixed sequence, not a single first-in-first-out queue. A callback's phase determines roughly when it can run, not the order you registered it in.

Microtasks - resolved Promises, queueMicrotask, process.nextTick - sit outside that phase cycle entirely. Node drains the microtask queue completely after every callback, not just once per full lap, so microtasks always get a chance to run before the loop moves from one phase (or one callback) to the next. That's why a Promise.resolve().then() reliably beats a setTimeout(fn, 0) even though both look like "run soon" - one is a macrotask waiting for its phase, the other cuts in immediately after the current callback finishes. Microtasks vs Macrotasks covers the exact ordering rules, including where process.nextTick fits.

The poll phase deserves special mention because it's where the loop spends most of its time in an I/O-bound app: when there's nothing else to do, libuv can let poll block, waiting on the OS for new I/O events, rather than spinning and burning CPU. That's the loop being efficient at idle - it's not busy-waiting, it's asleep until the OS wakes it up.

Advanced Considerations & Applications

The event loop is one point on a spectrum of concurrency models, and knowing where it sits clarifies what it's good at and what it isn't:

Node's choice - cooperative scheduling on one thread - is why the platform is unusually good at high-concurrency I/O and unusually bad at silently absorbing a CPU-bound mistake. There's no OS-level safety net; the loop trusts every callback to hand control back quickly. This is also why framework authors (Express, Fastify, NestJS) build routing and middleware around the assumption that handlers return control promptly - a blocking middleware doesn't just slow its own request, it delays the guard's entire round.

In production, that cooperative nature is exactly what you're watching for: rising event-loop delay or utilization (see Detecting Event-Loop Blockage) means some callback, somewhere, isn't cooperating. Event Loop Best Practices turns this model into concrete operational rules - what to keep off the main thread, and how to structure handlers so the loop stays free.

Common Misconceptions

• "The event loop is a single queue, and callbacks run in the order they were registered." It's a fixed sequence of phases, each with its own queue - a callback's type (timer, I/O, setImmediate) determines which phase handles it, not registration order alone.
• "Promises and setTimeout are scheduled the same way, just with different delays." They're different categories entirely - Promises are microtasks that drain between every callback; setTimeout callbacks are macrotasks tied to a specific phase. They aren't comparable by "delay."
• "The loop constantly polls in a busy-wait, burning CPU even when idle." The poll phase can block and let the OS wake it up when I/O is ready - an idle Node process isn't spinning a CPU core.
• "If I use async/await, the event loop can't get stuck on my code." async changes how a result is delivered, not whether the synchronous parts of that function can occupy the call stack. A long loop inside an async function blocks exactly as much as it would outside one.
• "The event loop guarantees my callback runs at a specific time." It guarantees relative ordering rules (microtasks before the next phase, timers phase before poll, etc.), never an exact timestamp - setTimeout(fn, 0) means "no earlier than," not "exactly at."

FAQs

Related

• How Node.js Works - the V8 + libuv picture this page builds on
• Event Loop Basics - hands-on examples of the ordering rules described here
• libuv Phases - what happens inside each phase, in detail
• Microtasks vs Macrotasks - the full microtask ordering rules, including nextTick
• Detecting Event-Loop Blockage - measuring loop health in production
• Event Loop Best Practices - operational rules that follow from this model

External Related Links

• Node.js API Documentation - Complete reference for core modules and APIs.
• Node.js Learn Guides - Official learning path.
• Node.js Best Practices (GitHub) - Curated production best practices.
• Node.js the Right Way - Server-side JavaScript fundamentals.
• Node.js Design Patterns, 4th Edition - Production-grade application patterns.

Stack versions: This page was written for Node.js 24.18.0 (Active LTS), npm 10+, and TypeScript 5.6+.