Do Online Timers Keep Running in Background Tabs?
By Mark Fulton · 2026-08-13 · 15 min read
You set a 10-minute timer, switched tabs to do something else, and came back to find it sitting at 3:47 with no chime, or showing the right time but never having made a sound. Yes, an online timer keeps running when you switch tabs — but browsers deliberately slow down background pages, so a timer built to count ticks falls behind while a timer built to watch the clock stays correct. The difference is invisible until it costs you. A well-built timer stores the moment it should end and compares it against your system clock, which means the number you come back to is right no matter how long the tab sat in the background. What throttling genuinely can delay is the chime, by up to a second in a recently-used tab and up to a minute in one that has been hidden for a while — and if the tab is frozen, discarded, or closed, nothing fires at all.
That is the whole answer. The rest of this post is the detail behind it: what browsers actually do to a background tab, why the count can be perfect while the alarm is late, exactly what happens when your phone locks, and how to set a timer you can walk away from without checking on it.
Why does a browser timer miss its alarm?
There are two ways to build a countdown, and they behave completely differently the moment you look away.
The naive way is to count ticks. The page asks the browser to run a small function every second, and that function subtracts one from a number. Ten minutes is 600 of those. This works flawlessly while you are watching it, and it is how a surprising number of web timers are written, because it is the obvious way to do it.
The problem is that the browser never promised to run that function every second. It promised to run it no sooner than every second. When your tab goes into the background, the browser starts running it much less often to save battery and CPU — and every skipped run is a second the timer never subtracted. Come back after ten real minutes and the counter might read three minutes remaining, because it only got to count 420 times instead of 600. The timer did not stop. It undercounted, which looks the same from the outside and is worse, because it will eventually fire at the wrong moment rather than not at all.
The other way to build it is to write down the finish line. When you press start on a 10-minute timer, the page records a single number: the wall-clock moment ten minutes from now. After that it does not count anything. It just asks "what time is it, and have we passed the finish line yet?" It can ask that once a second, once a minute, or once when you come back to the tab, and the answer is always right, because the answer comes from your system clock rather than from the page's own bookkeeping.
That is how the timers on this site are built, and it is worth being concrete about it since this is the actual mechanism the whole question turns on. When you start a timer here, the page stores an absolute end timestamp — the current epoch time plus the duration — and every display afterwards is computed as endAt - now. There is no accumulating counter to fall behind. The stored timestamp lives in your browser's local storage, and the piece of code that owns it is mounted at the top of the app rather than inside any one page, which is why a running timer survives clicking through to the stopwatch or the world clock, and why it survives a full page reload. Reloading the tab re-reads the deadline and picks the countdown up mid-flight.
What is timer throttling and why do browsers do it?
Throttling is the browser deciding that a page you are not looking at does not deserve full CPU. It is a battery and performance measure, and it has been getting steadily more aggressive for a decade, because the alternative is a laptop with forty tabs open running forty pages' worth of animation loops and ad scripts at full speed.
Chrome's public description of the design, in its engineering post on background tabs, is a budget system: "Each background tab has a time budget (in seconds) for running timers in the background," and "The budget continuously regenerates with time (currently set to a rate of 0.01 seconds per second)." A timer task is allowed to run only while that budget is non-negative, and its run time is deducted after it runs. The budget kicks in after a delay — "A page is subjected to time budget limitations after 10 seconds in the background."
Two exemptions in that same document matter for anyone building a timer. "Applications playing audio are considered foreground and aren't throttled," and pages holding real-time connections (WebSockets and WebRTC) are also spared, so those connections don't die of timeout.
Mozilla's reference documentation goes further and puts numbers on the tiers. Per MDN's notes on timeouts in inactive tabs, Chrome runs three levels: minimal throttling for pages that are visible or have made sound recently, where "Timers run close to the requested interval"; ordinary throttling, where "Timers in this state are checked once per second"; and intensive throttling, introduced in Chrome 88, where "Timers in this state are checked once per minute." That last tier applies when the page has been invisible for more than five minutes, silent for more than thirty seconds, has no active WebRTC, and has chained timers nested five deep or more.
So the honest picture for a background tab is not "the timer stops." It is "the browser checks in less often" — roughly once a second at first, and potentially only once a minute after five quiet minutes. The countdown itself is fine. The check is what gets rationed.
Does elapsed time stay correct even when the tab is hidden?
Yes, and this is the part that almost nothing written about background tabs makes clear to a non-developer, because the developer answer and the human answer point in opposite directions.
Your system clock never stops. It is not a browser feature; it is the machine's clock, and it keeps perfect time whether the tab is hidden, minimised, or asleep. Any page that reads it is reading the truth. So the question "does elapsed time stay correct in a background tab?" has a clean answer: elapsed time is always correct, because elapsed time is just two clock readings subtracted. What throttling affects is how often the page bothers to look.
That distinction resolves most of the confusion. If you come back to a hidden tab and the number is wrong, you are not looking at a browser that lost time. You are looking at a timer that was counting its own ticks instead of reading the clock. If you come back and the number is right but no sound played, you are looking at a correctly-built timer whose check simply had not come around yet — and it will fire the moment it does, which for a visible tab is immediately.
The same logic applies to a repeating timer. Ours rolls the next deadline forward from the previous deadline rather than from the moment it noticed, so an interval checked ten minutes late is still on its original cadence instead of drifting a bit further every cycle. Small thing, but drift compounds, and a rest timer that has silently slid four minutes off over an hour is not a rest timer any more.
Where the count can genuinely be wrong is the one case people forget: if you change your device's clock or cross a time zone mid-countdown, a deadline-based timer will move with it. That is a real trade-off of the approach, and for a timer measured in minutes it essentially never comes up. If you want the mechanics of why your clock jumps at all, we went through that in how UTC, time zones and DST actually work.
What happens when the phone locks or the tab is discarded?
This is where the answer changes from "it works" to "it depends," and it is worth being blunt about the failure cases rather than pretending a browser tab is a phone alarm.
The key fact from MDN's Page Visibility API documentation is that a page counts as hidden not only when you switch tabs but "because the device's screen is off." A locked phone is, as far as the page is concerned, a background tab — and mobile browsers are far more willing to reclaim memory than desktop ones. The same MDN page notes windows are subject to throttling after thirty seconds, with a budget regenerating "at a rate of 10 ms per second, in both Firefox and Chrome."
Past throttling, there are two harder states. Chrome's page lifecycle documentation describes frozen, where "the browser suspends execution of freezable tasks in the page's task queues until the page is unfrozen. This means things like JavaScript timers and fetch callbacks don't run" — nothing at all executes, so nothing can make a sound. Then discarded, where the page is thrown away entirely to free memory: "the tab itself (including the tab title and favicon) is usually visible to the user even though the page is gone," and discarded pages "must be reloaded to use again." That is the case that fools people, because the tab is still sitting there in the tab strip looking perfectly alive.
Here is every state a tab can be in, what happens to the count, and what happens to the alarm:
| Tab state | Does the count stay right? | Does the alarm fire? | What to do instead |
|---|---|---|---|
| Visible (front tab, screen on) | Yes | Yes, on time | Nothing — this is the reliable case |
| Hidden (you switched tabs, under ~5 min) | Yes, if the timer reads the clock | Yes, up to about a second late | Fine to walk away; keep the window open |
| Throttled (hidden and quiet over 5 min) | Yes, if the timer reads the clock | Yes, but up to a minute late | Fine for cooking and breaks; not for a hard cutoff |
| Frozen (browser suspended the page) | Yes — recomputed on unfreeze | No sound while frozen; fires on return | Keep the tab in the foreground window, or use a phone alarm |
| Discarded (browser reclaimed the memory) | Yes, if the deadline was saved to storage | No — the page no longer exists | Reload the tab; a stored deadline resumes mid-flight |
| Closed (you closed the tab or quit) | Deadline survives in storage | No | Use your phone or OS alarm for anything that matters |
| Phone locked (screen off) | Yes, if the timer reads the clock | Unreliable — often not until you wake the screen | Use a wake lock, or your phone's built-in alarm |
The pattern in that last column is the honest summary: a browser timer is excellent while the browser is awake and open, degrades gracefully to "correct but late" as the tab goes quiet, and stops being an alarm at all once the page is gone. Anyone telling you a web page can reliably wake a locked phone is overselling.
We handle the middle of that table and are open about the ends. While a timer is live, the site requests a screen wake lock so the display does not sleep out from under it, and re-requests it when you come back to the tab, since the lock is released when the page is hidden. The running countdown is also written into the tab title, so a backgrounded tab shows its own remaining time in the tab strip without you switching to it. And the chime is synthesized in the browser with Web Audio rather than loaded as a sound file, with the audio context created inside the click that starts the timer — that is what stops autoplay policy from silencing the alarm later, which is the other common reason a timer "doesn't go off."
What we deliberately do not do is ask for notification permission or install a service worker. That would let a chime survive a closed tab, at the cost of a permission prompt on a site whose whole point is that nothing is installed and nothing is asked of you. The trade-off is real and it is stated plainly: keep the tab open.
Which browsers behave worst?
There is no single villain, but the documented behaviour does differ, and mobile is where it gets rough.
Per MDN, Firefox Desktop "has a minimum timeout of 1 second for inactive tabs" — simple and predictable. Firefox for Android is the outlier: it "has a minimum timeout of 15 minutes for inactive tabs and may unload them entirely." Fifteen minutes is longer than most timers people set, so a backgrounded timer on Android Firefox is a coin flip.
Chrome is gentler at first and stricter later, via the three tiers above: close to the requested interval when visible or recently noisy, once a second when hidden, once a minute after five quiet minutes.
One genuinely useful detail from the same MDN page: "Firefox does not throttle inactive tabs if the tab contains an AudioContext," and Chrome's minimal-throttling tier covers pages that have "made sound recently." Our timers do create an audio context the moment you start one, which satisfies the Firefox condition as documented. It is worth being precise rather than claiming more than we can: that context is silent until the timer fires, so it does not meet Chrome's "made sound recently" bar, and a long quiet Chrome tab will still slide into the once-a-minute tier.
The practical ranking, then: a desktop browser with the window open is dependable. A background tab on desktop is dependable for the count and approximate for the chime. A mobile browser with the screen off is the one to stop trusting for anything you cannot afford to miss.
How do you set a timer you can walk away from?
Five things, in order of how much they help.
Pick a timer that shows you its end time, not just its remaining time. If a timer tells you it "ends at 3:42," it is reading a clock rather than counting ticks, and you can verify it yourself against any other clock in the room. Ours displays the end time under the countdown while it runs, for exactly this reason.
Leave the browser window open and unminimised if you can. Everything above gets easier in the visible state. A second window beside your work is better than a background tab, and a background tab is much better than a closed one.
Use the tab title as your glance. You do not have to switch back to check. The remaining time is in the tab strip, which also means the timer is still alive.
Don't rely on it through a screen lock. For a nap, a school run, or anything with a consequence, use your phone's built-in alarm. That is not a weakness in web timers specifically — it is the difference between an app the OS wakes up and a page the OS is entitled to freeze.
Reload rather than panic. If you come back to a tab that looks dead, reload it. Because the deadline is stored rather than counted, a reloaded page picks the countdown back up where it genuinely is, instead of starting over.
One last note for the common case that brought most people here: for cooking, workouts and focus blocks, a background browser tab is fine. A chime up to a minute late does not ruin pasta, and the pomodoro block you were running does not care either. It is worth knowing which of your timers are in the "fine" column and which are in the "use your phone" column, and now you do.
Set a timer that counts from the clock rather than from ticks. Open the countdown timer, dial in your duration, and it will show you the exact time it ends so you can walk away and check the tab title instead of the page. If you want something to go off at a set time rather than after a set duration, the online alarm clock works the same way — it compares the current time against the time you set, so a backgrounded tab does not shift it. Both are free, with no account and nothing to install, and no clock, timer or alarm on this site is ever behind a paywall.
FAQ
Will an online timer go off if I switch tabs?
Usually yes. Switching tabs does not stop the page; it moves it into a throttled state where the browser checks its timers less often — roughly once a second at first, and as little as once a minute after the tab has been hidden and silent for about five minutes. A timer built on an end timestamp will still show the correct remaining time when you return and will sound as soon as its next check comes around. It will not fire if the browser has frozen or discarded the page to save memory, or if you closed the tab. Keeping the window open and unminimised is the single thing that makes it reliable.
Does a browser timer work when the screen is off?
Treat it as unreliable. Browsers consider a page hidden when the device's screen is off, which is the same state as a background tab, and mobile browsers are much quicker to suspend or unload pages than desktop ones. A screen wake lock, which our tools request while a timer runs, keeps the display awake and avoids the problem entirely — but if the phone locks anyway, the chime often will not sound until you wake the screen. For anything you cannot afford to miss with the phone in your pocket, use the phone's own alarm app. The elapsed time will still be correct when you look; it is the sound you cannot count on.
Why is my online timer a few seconds late?
Almost always throttling, and the lateness is in the alarm rather than the count. A hidden tab has its timer checks batched, so a deadline that passes at second 600 may not be noticed until the next check — about a second later in a recently-used tab, up to a minute in one that has been quiet for over five minutes. The other common cause is a timer that counts ticks instead of reading the clock, which produces the opposite symptom: it finishes late by however much time it failed to count, sometimes minutes. If your timer's remaining number is wrong when you return, it is the second problem, and no setting will fix it.
Is a browser timer as reliable as a phone alarm?
For anything with the tab open and the screen on, yes, and it is more convenient. For anything that has to survive a locked phone, a closed tab, or a browser deciding to reclaim memory, no — and no browser tab can honestly claim otherwise, because a phone alarm is registered with the operating system and a web page is not. The sensible split is to use a browser timer for cooking, workouts, focus blocks and anything you are sitting near, and your phone's alarm for waking up, catching transport, and anything where missing it has a real cost.