Browser timing limitations

Browser throttling

Browsers deliberately slow down JavaScript timers (setTimeout, setInterval) in tabs that aren't active, to save battery and CPU across all your open tabs. A timer asked to fire every second can be throttled to once every several seconds, or longer, once the tab is in the background. This is a built-in browser optimization, not a bug in the page — every website's timers are throttled the same way.

Background tabs

A "background tab" is any tab that isn't the one currently on screen — you switched to check email, opened another window, or your phone locked. Alarms and timers keep running in the background, but throttling (above) means the countdown display can lag, and on some browsers and devices the tab can be suspended or unloaded entirely to free up memory, especially if you have many tabs open or the device is low on RAM. If the tab itself is discarded, nothing further can fire until you switch back to it.

The Wake Lock API

Wake Lock is a browser feature that can keep a device's screen from automatically turning off while a page is open — useful for a full-screen bedside alarm or a kitchen timer you want to glance at. It does not keep a background tab running at full speed, prevent the operating system from suspending the browser app entirely, override a phone's silent or Do Not Disturb mode, or work at all unless the tab stays in the foreground. It solves one narrow problem (the screen dimming) and nothing else.

How the full-screen alarm clock uses it: opening full-screen bedside mode requests a screen wake lock the moment it starts, and releases it the moment you exit. If the lock isn't supported on your browser, if the tab loses focus even briefly, or if the OS overrides it anyway, the page re-requests the lock automatically as soon as the tab is visible and active again — but the screen can still go dark in between, so it's a best-effort hold, not a guarantee. Holding that lock for hours, especially overnight, is exactly the kind of extended, static, full-brightness display use that carries its own risks — see screen warnings for burn-in and overnight-use guidance before you leave it running all night.

Mobile OS behavior

Phones and tablets are more aggressive than desktops about reclaiming resources from apps and tabs the person isn't actively looking at. iOS Safari can suspend a background tab's JavaScript within seconds of switching away, and reloads the page from scratch when you return — any in-progress alarm or timer state in that tab is gone. Android's behavior varies by manufacturer: many OEM battery managers apply their own, more aggressive restrictions on top of what Chrome or the OS already does, and can suspend a browser tab even while it's technically "open." None of this is specific to alarm-clock.org — it applies to every site's browser-based timer.

Battery optimization

Low Power Mode (iOS), Battery Saver (Android, Windows) and similar OS-level features reduce background CPU activity to extend battery life. A browser tab running a countdown is exactly the kind of background activity these features are designed to throttle. The tradeoff is deliberate on the OS's part — battery life over background timing precision — and there's no setting on alarm-clock.org's side that can override it.

What we do to minimize CPU and battery use

The one piece actually under our control is how often our own scripts ask the browser to do anything, so we keep that as light as the job allows rather than polling every second by default:

• The alarm clock's display and its check for whether an alarm should fire both run once a minute, aligned to the start of the minute — not once a second. The display doesn't show seconds, and firing on time only needs minute-level precision, so there's no reason to wake the browser 60 times more often than that.
• World Clock updates on the same once-a-minute schedule, and stops entirely via the Page Visibility API while its tab isn't visible, picking back up the moment you return.
• Full-screen bedside mode's anti-burn-in position nudge (see Wake Lock, above) moves the display once an hour, not continuously.

This doesn't change the limits described elsewhere on this page — a background tab can still be throttled or suspended by the browser or OS no matter how efficiently our own code runs — it just means we're not adding unnecessary CPU wake-ups on top of that.

Why browser timing cannot be guaranteed

Web browsers were never designed as real-time systems. JavaScript's timing functions are explicitly best-effort: the spec allows the browser to delay a scheduled callback for throttling, other work on the page, or system load, and every browser and OS combination applies its own additional layer of power-saving behavior on top of that. Combine that with a phone that can lock, sleep, suspend the tab, or kill the browser app outright, and there's no way for any website — this one included — to promise that a background timer will fire at the exact millisecond, or fire at all, if the device has gone to sleep in the meantime.

Keeping the tab open and on screen (or using full-screen bedside mode for the alarm) avoids almost all of this, because an active, visible tab isn't throttled the same way a background one is.

Use a dedicated device for anything critical

alarm-clock.org is built for convenience — a quick timer while cooking, an alarm for a nap, a stopwatch for a workout, a countdown to share. For anything where missing the moment has real consequences — waking up for a flight, a medication reminder, a safety-critical alert — use a purpose-built alarm clock, your phone's native (non-browser) alarm app, or another dedicated device designed to run reliably while your screen is off and your browser is asleep. Those tools are built to work outside the constraints described on this page; a browser tab fundamentally is not.

Planning to leave the alarm's full-screen bedside mode open overnight? That's a screen hardware question, not a timing one — see screen warnings for burn-in risk and manufacturer guidance.