Why You Should Avoid Using setInterval in JavaScript

When building an online chat tool or any client‑side periodic task, developers often reach for setInterval to run a function every few milliseconds. This article explains three fundamental problems with that approach and shows why setTimeout is a safer alternative.

Reason 1 – setInterval ignores code errors

If the function executed by setInterval throws an exception, the timer keeps invoking it regardless, potentially flooding the console with repeated failures. The following example demonstrates a function that throws an error inside a try…catch block; the interval continues even after the exception.

function a() {
    try {
        a.error; // will throw
    } catch (e) {
        $('body').append('
' + e + '
');
        throw e; // re‑throw
    }
}
function b() {
    try {
        b.error; // will throw
    } catch (e) {
        $('body').append('
' + e + '
');
        throw e;
    }
    setTimeout(b, 2000);
}
setInterval(a, 2000);
setTimeout(b, 2000);

Reason 2 – setInterval ignores network latency

When polling a server with Ajax, the request may take longer than the interval period because of server load, network issues, or client bandwidth limits. setInterval still fires at the fixed rate, causing the request queue to fill up. The code below shows a naive polling loop that quickly exceeds the intended request rate.

var n = 0, t = 0, u = 0, i, s = 'Stopping after 25 requests, to avoid killing jsfiddle’s server';
function a() {
    $.post('/ajax_html_echo/', function () { --n; });
    ++n;
    ++t;
    $('#reqs').html(n + ' a() requests in progress!');
    if (t > 25) {
        clearInterval(i);
        $('#reqs').html(s);
    }
}
i = setInterval(a, 500);
setTimeout(b, 500);

In the second variant, a recursive setTimeout is used, allowing the loop to stop cleanly after the limit is reached.

function b() {
    ++u;
    $.post('/ajax_html_echo/', function () { /* … */ });
    if (u <= 25) {
        setTimeout(b, 500);
    } else {
        $('#req2').html(s);
    }
}
i = setInterval(b, 500);
setTimeout(b, 500);

Reason 3 – setInterval does not guarantee execution

Unlike setTimeout , setInterval cannot ensure that a callback runs exactly after the specified delay. If the callback takes longer than the interval, some invocations are skipped. The following example uses a synchronous Ajax call to illustrate timing drift.

function slow() {
    $.ajax({
        url: '/echo/html/',
        async: false,
        data: { delay: 1 },
        complete: function () {}
    });
    $('#reqs').text(~ ~ (new Date() - start) / 100 + ' expected, ' + iters + ' actual');
    if (iters++ > 4) {
        $('#reqs').append('
Stopping after 5 iterations');
        clearInterval(iv);
    }
}

Solution – use setTimeout instead of setInterval

Replace the fixed‑rate interval with a self‑rescheduling setTimeout . After each execution, schedule the next call, optionally adjusting the delay based on how long the previous call took. This approach prevents error accumulation, respects network latency, and gives you control over the exact timing.

If you need perfectly uniform intervals, compute the next delay as the desired period minus the elapsed time of the previous call, but remember that JavaScript timers are not perfectly precise and browsers enforce a minimum timeout of 4–15 ms.