How accurate is an online timer?
It depends on one design choice most timers never mention: do they count seconds, or do they check the clock? Here is what browsers do to background tabs, what that does to your alarm, and where the real limits are.
Browsers slow down hidden tabs, on purpose
When a tab isn’t visible, browsers throttle its timers to save power. The details vary, but the pattern is well documented:
- Chrome limits timers in background tabs to about once per second, and after a tab has been hidden for five minutes, applies “intensive throttling” that can batch timer callbacks to once per minute (Chrome 88 onwards, per the Chrome for Developers blog).
- Firefox and Safari apply similar background budgets, and Safari on iOS may suspend a background page entirely.
- Mobile browsers can freeze a background tab completely, so nothing runs until you come back.
A timer that works by “every second, subtract one” simply misses those seconds. Play with the simulator to see how late it gets.
Timestamp timer (CountdownPro): rings at 10:00, every time.
Tick-counting timer: rings at 13:56, which is 3:56 late.
How CountdownPro keeps time instead
- Store the end moment, never count. When you press Start, the timer saves end = now + duration. Whatever it’s showing is always end − now from the system clock, so a late or skipped refresh can’t make it drift. The same end time is saved in your browser, which is why timers survive reloads.
- Book the sound in advance. The alarm is scheduled on the Web Audio clock at the moment you press Start, not triggered by a page timer at the end. Audio scheduling is handled by the browser’s audio system and is not subject to the same timer throttling, so the alarm lands on time in a background tab.
- A second, independent alert. A single timeout aimed at the end time fires the system notification and the on-screen flash. Throttling may delay that by around a second in a hidden tab, rarely more for one well-aimed timeout, and it never adds up.
- Keep the screen on. While a timer runs, the page asks for a Screen Wake Lock (where supported) so phones don’t lock and freeze it.
The honest limits
Some things no web page can get around. It’s better you know them before relying on an alarm:
| Situation | Countdown shown | Alarm sound |
|---|---|---|
| Tab visible | Smooth, exact | On time |
| Other tab or app, same window open | Updates at least once a second or so; correct whenever it updates | On time (audio was pre-booked) |
| Phone locked, browser frozen | Correct the moment you unlock | May not play until you return |
| Computer asleep | Correct on wake | Does not play while asleep |
| Tab or browser closed | Restored on reopen (shows finished) | Does not play |
| Muted device / sound blocked until first tap | Correct | Silent; tap the page once so sound can play |
For anything where a missed alarm matters (medication, a flight, a child’s pickup), use the alarm built into your phone’s operating system, which can wake the device.
What “accurate” means for the clock itself
Every timer is only as good as the clock it reads. Phones and computers keep time with a quartz crystal, which can drift by a second or so a day, and quietly correct it by syncing to internet time servers (the Network Time Protocol). Over a 10-minute timer, that drift is far smaller than anything you’d notice. The Moon runs to no such correction, which makes its phases a satisfying bit of clockwork to understand; ahaboo narrates why they happen.
Shareable countdown links have one extra problem: they must agree across devices. If someone’s clock was set by hand and is off by two minutes, a naive countdown would end two minutes early for them. The countdown link tool compares the device clock with our server when it loads and corrects for the difference.