Timers: setTimeout & setInterval

Timers are reminders, not pauses

JavaScript runs one piece of code until that piece is finished. A timer does not freeze the program in place. Instead, a host such as the browser or Node.js keeps a reminder and calls your callback later. That fits the previous lesson’s idea: the host does the waiting, and the callback runs after the current JavaScript has finished.

In this lesson, setTimeout schedules one future callback, setInterval schedules repeated callbacks, and the matching clear... functions cancel work you no longer want. You will measure real delays in your own tab because timing is famously environment-dependent: device speed, tab visibility, battery saving, and page load all matter.

setTimeout(callback, delay) returns immediately. In browsers it returns a numeric id; in Node.js it returns a Timeout object. Either way, keep that value if you might cancel the timer. The optional values after the delay are passed to the callback as arguments when it runs.

setTimeout((name, count) => {
  console.log(name + " has " + count + " reminders");
}, 1000, "Ada", 3);

The source below schedules two timeouts, cancels one, and logs synchronously before the callbacks get a chance. Step through the real order: a timeout with 0 still runs later, not in the middle of the current script.

1console.log("A: start");Run2const keep = setTimeout(() => console.log("D: 20ms timeout"), 20);3const cancel = setTimeout(() => console.log("never runs"), 10);4setTimeout(() => console.log("C: 0ms timeout"), 0);5clearTimeout(cancel);6console.log("B: end");

Cancellation is most important during cleanup. If a component resets, unmounts, or navigates away, clear any pending timer so an old callback does not update stale UI.

1const started = performance.now();2const id = setTimeout(() => {3  const actual = performance.now() - started;4  console.log(actual);5}, 500);6 7// Optional: block the thread before the callback can run.

setInterval(fn, 500) is a metronome: it keeps trying to tick every 500 ms. That is fine for a clock or simple repeated check. But if the work sometimes takes longer than expected, interval callbacks can bunch up or overlap with async work you started inside them.

setInterval(async () => {
  await saveSlowly();
}, 500);

async function loop() {
  await saveSlowly();
  timeoutId = setTimeout(loop, 500);
}

1setInterval(tick, 500);2 3function nestedTick() {4  doSlowWork(150);5  setTimeout(nestedTick, 500);6}

The right choice is practical: choose setInterval for regular lightweight ticks; choose nested setTimeout when each run should finish before the next delay starts, or when the next delay changes after every attempt.

A delay of 0 means “as soon as the host is allowed to run this callback,” not “right now.” Browsers also protect the page and the device by enforcing minimum delays in some situations. The HTML spec clamps nested timers to at least 4 ms after five levels of nesting. Your measured numbers may be larger or noisier.

1let depth = 0;2let last = performance.now();3 4function next() {5  const now = performance.now();6  console.log(depth, now - last);7  last = now;8  depth += 1;9  if (depth < 10) setTimeout(next, 0);10}11 12setTimeout(next, 0);

The trustworthy sentence is: a timeout waits at least the requested delay. It can be later because the current script is busy, another callback is running, the browser throttles a background tab, or the device is under load. Background browser tabs are commonly throttled to about once per second, and some browsers become more aggressive in certain cases.

This is why every timing demo in this lesson measures with performance.now() after you click. The displayed results are not copied from the author’s machine; they are measured on this device, in this tab, now.

Where you’ll use timers

Timers show up in user interfaces constantly: hiding a toast, debouncing search input, retrying a request, showing a countdown, and stopping a spinner if something takes too long. Two published lessons connect closely: Closures in loops, timers & memory explains the classic loop variable problem, and Losing this explains why setTimeout(obj.method) can detach a method from its object.

let timeoutId;
let stopped = false;

async function poll() {
  await loadLatestData();
  if (!stopped) timeoutId = setTimeout(poll, 1000);
}

poll();

function stopPolling() {
  stopped = true;
  clearTimeout(timeoutId);
}

Notice the cleanup story: stopped prevents scheduling another timeout, and clearTimeout(timeoutId) cancels a waiting one. Real apps put that cleanup in a Reset button, a component unmount effect, or a route-change handler.

Common misconceptions

• “0 ms means immediately.” It means later, after the current script and only when the host can run the callback.
• “500 ms means exactly 500 ms.” It means at least 500 ms; busy code and throttling can delay it.
• “Intervals wait for async work.” They do not know whether your promise finished. Use nested timeouts or explicit guards.
• “Clearing after a timeout fires changes history.” Clearing only cancels a pending timer. Once a callback ran, it ran.
• “Huge delays are safe reminders.” Values above 2 ** 31 - 1 ms overflow in Node and are unsafe in browsers too.
• “Timer ids are the same everywhere.” Browsers use numbers; Node returns objects.

Key takeaways

• setTimeout schedules one future callback; clearTimeout cancels it before it runs.
• setInterval repeats until clearInterval; nested setTimeout gives you one full gap after work finishes.
• Timer delays are minimums. Measure real behavior with performance.now() when precision matters.
• Nested timers are clamped after several levels, background tabs are throttled, and huge delays can overflow.
• Always clean up timers on Reset, unmount, navigation, or Stop.

Final definition: a JavaScript timer is a host-managed reminder that queues a callback later, never an exact pause in the current code.

Up next: The event loop.