Introduction

setTimeout does not run its callback exactly on schedule, and it definitely does not interrupt currently running JavaScript. It only says, "after at least this delay, place this callback where it can run later." If the call stack is busy with synchronous work, the callback waits. That is why setTimeout often looks blocked.

What setTimeout Actually Guarantees

When you call setTimeout(fn, 1000), JavaScript does not promise that fn runs one second later. It promises only that the callback will not be eligible to run before roughly one second has passed.

The callback still needs two things before it can execute:

• the timer delay must expire
• the call stack must be clear

That second condition is what surprises people.

A Simple Example

1console.log("start");
2
3setTimeout(() => {
4  console.log("timeout callback");
5}, 0);
6
7console.log("end");

Output is:

start
end
timeout callback

Even with 0 milliseconds, the callback does not run immediately. It waits until the current synchronous code finishes.

Why It Looks Blocked

Consider this example with a long synchronous loop:

1console.log("before timer");
2
3setTimeout(() => {
4  console.log("timer fired");
5}, 100);
6
7const start = Date.now();
8while (Date.now() - start < 3000) {
9  // Busy loop for 3 seconds.
10}
11
12console.log("after loop");

The timer delay expires during the loop, but the callback still cannot run until the loop finishes and the stack clears. That means the actual output is closer to:

before timer
after loop
timer fired

The timer was not blocked by the timer system. It was blocked by your own synchronous code keeping JavaScript busy.

Event Loop Mental Model

The useful model is:

• 'setTimeout registers a timer with the host environment'
• when the delay expires, the callback becomes ready
• the event loop can move that callback onto the call stack only when the stack is empty

So the callback is delayed by both time and availability of the thread.

This also explains why browser UI may freeze while timers seem late. JavaScript on the main thread is single-threaded from the point of view of your code execution.

setTimeout(..., 0) Is Not Immediate Execution

Many developers use setTimeout(..., 0) expecting "run now, but after this line." The closer truth is "run later, as soon as the event loop gets a chance."

That can still be useful for:

• deferring noncritical work
• yielding after current synchronous logic finishes
• allowing the browser to handle pending tasks first

But it is not a way to bypass blocking code.

Real Cause: Long Synchronous Tasks

If a timer feels blocked, the real culprits are usually:

• heavy loops
• expensive rendering work
• large JSON parsing or data transformation
• synchronous XHR in older code
• recursive logic that monopolizes the main thread

The fix is not to add more timers. The fix is to reduce or split up the blocking work.

Breaking Work Into Chunks

If you need to process a lot of data without freezing the thread, split it into smaller batches.

1const items = Array.from({ length: 10000 }, (_, i) => i);
2
3function processChunk() {
4  const chunk = items.splice(0, 500);
5
6  for (const item of chunk) {
7    // Simulate work.
8    Math.sqrt(item);
9  }
10
11  if (items.length > 0) {
12    setTimeout(processChunk, 0);
13  } else {
14    console.log("done");
15  }
16}
17
18processChunk();

This lets the event loop breathe between chunks. The timer is now helping scheduling instead of competing with one giant blocking task.

Promises Do Not Change Blocking Synchronous Code

Switching from setTimeout to promises does not fix a CPU-heavy loop. Microtasks and macrotasks differ, but neither can preempt currently running synchronous JavaScript. If the thread is busy, queued work still waits.

The broader rule is simple:

• asynchronous scheduling is not the same as parallel execution

If true parallelism is needed for heavy computation in the browser, use Web Workers. In Node.js, use worker threads or move the work to another process when appropriate.

Common Pitfalls

• Expecting setTimeout(fn, 0) to run immediately.
• Assuming the numeric delay is an exact execution time rather than a minimum delay.
• Using timers to "fix" code that is really blocked by long synchronous work.
• Forgetting that browser JavaScript on the main thread is single-threaded for execution.
• Confusing delayed callbacks with background parallel computation.

Summary

• 'setTimeout schedules a callback for later; it does not interrupt running code.'
• The callback runs only after the delay expires and the call stack is free.
• Long synchronous tasks are the main reason timers appear blocked.
• Use chunking, better scheduling, or workers when the main thread is overloaded.
• A timer delay is a minimum wait, not a guarantee of exact execution time.