Why Your Phone Alarm Fails — and Why Web Timers Have the Same Problem

The ordinary reasons an alarm you trusted did not fire, why a perfectly written web timer has the same weakness, and what it genuinely can and cannot do about it. Honest answers, with the measurements we actually ran.

By Ivo Buljeta, the engineer behind StopwatchHQ · Published Oct 12, 2026

Almost everyone has a story about an alarm that did not go off. The failure is rarely the clock — the phone knew the time perfectly. What failed was the wake-up: the thing that was supposed to make a noise at the right moment. Web timers inherit the same weakness, and a timer that trusts the browser to keep its schedule is closer to a phone alarm than its author would like to admit.

The one-line answer

An alarm only fires if something wakes up at the right time to fire it. Phones suppress wake-ups to save battery; browsers throttle and suspend them to save CPU. A web timer that counts ticks inherits every one of those delays. A timer that stores a wall-clock target, and checks it whenever it is next woken, keeps the correct time no matter how late the wake-up is — but the beep can still be late, for exactly the reason your phone alarm was. Keeping the tab visible is the web's version of checking the silent switch.

Why a phone alarm fails

The reason depends on which alarm you mean. A phone's own built-in alarm is treated as a privileged, system-level event, so the everyday suspects often do not stop it:

Silent mode and Do Not Disturb generally do not silence the built-in alarm. On iOS the Clock alarm sounds even with the ring/silent switch on, and Focus/DND do not block it by default; Android is similar for the system clock app. What those settings do reliably suppress is notifications — and any alarm or reminder implemented as one.
Third-party alarm apps are the fragile ones. An app that is not allowed to run in the background, is killed by battery optimisation, or is swiped away can miss its wake-up entirely. That is why "my alarm app didn't go off" almost always refers to a downloaded one.
Built-in alarms do fail, but for duller reasons: the alarm volume left low or muted, the alert routed to a Bluetooth speaker that is out of earshot, or the phone simply off or out of battery.

The lesson worth carrying across to the web is not the specific setting. It is that the timekeeping was never the problem. The wake-up was.

The web version of the same problem

A browser tab has its own wake-up problem. We measured it directly: a page opened in Chrome 154 on Linux, allowed to start, then backgrounded by activating a second tab — the same intent as clicking away, though not identical to a minimised window. We logged every timer callback with a timestamp and the page's visibility state.

A setInterval(100) that ran ten times a second while the page was visible was clamped to roughly once a second the moment the tab went to the background. A one-second timer was stretched toward two seconds per tick — a doubling we observed but that is not one of Chrome's documented tiers, so we report it as an observation rather than a rule. This is the same story as the phone: the timer did not stop, but its wake-ups were rationed.

And here is the honest part that most timer pages leave out. A tick-counting timer loses time, because it counts the callbacks the browser stopped sending. A timestamp-based timer keeps the correct time — the displayed value is right the instant anything wakes it — but the alert can still fire late by up to a second, or much longer once harsher throttling applies. Timestamps fix the reading, not the wake-up. For an exact alarm, that is the same limitation your phone imposes, and no amount of clever JavaScript removes it. (The full numbers are in our background-tab measurement.)

The three options people reach for, and what each really does

Play a sound to stay awake. Browsers will not let a page make sound until the user has interacted with it — the autoplay policy — so an alarm tone has to be "unlocked" on a real tap or click. That part is unavoidable and real: without the gesture, an alarm tone simply will not play at all, and the unlock is lost on every reload, so the page has to ask again. It is also commonly claimed that playing audio exempts a tab from throttling. We tested it, and in our headless run a page playing a silent oscillator was still clamped to about one callback per second once hidden, so we will not claim audio keeps a hidden tab fast. Chrome documents that audio exempts a tab from the harsher, later "intensive" tier, not from the first clamp — and headless Chrome has no audio device, so it may not have registered the playback as audible at all. (On iOS the silent switch can mute web audio too, which ties straight back to the phone section.)
Wake Lock. The Screen Wake Lock API can keep the screen from sleeping while the page is visible. It does nothing for a backgrounded or suspended tab, and it needs a secure context and often a user gesture. It is for "keep the screen on while I watch this", not for guaranteed alarms.
Service workers and notifications. Useful for showing a notification, but browsers do not guarantee when a background service worker runs, and notification delivery is best-effort. Neither gives you an exact alarm.

How the timers on this site cope

We store a wall-clock target and recompute. Elapsed time is always derived from a stored timestamp, so a late tick shows the right number. We use the monotonic performance.now() for measuring elapsed time within a session, and a real date/time for a target the user set — the former never jumps when the system clock is corrected, the latter is what "6:30" actually means to a person.
We unlock audio on your first tap and say so on the page. It is why an alarm page asks you to tap once: without it, it is not allowed to beep.
We tell you the tab has the final say. For anything that cannot be late, we point you to your phone's own alarm clock rather than imply the page can outsmart the operating system.

What this means for you

If an alarm must fire at an exact second, use your phone's built-in alarm clock, keep the alarm volume up, and leave the phone off its "optimised" charging profile if alarms have let you down before.
If you are timing something at the screen, the countdown timer, pomodoro and interval timer here keep correct time because they read the clock rather than count ticks.
If you leave a web timer in a hidden tab, expect a late alert however well it is built. Keep the tab in front of you. That is the platform, not the page.

Limitations, stated plainly

One platform, headless, n=1. Every number is a single run of Chrome 154 on one Linux desktop, headless, with the page hidden by activating a second tab. Headless is not a normal desktop, and this is not a phone. Read the numbers as a clear illustration of documented behaviour, not a statistical result.
The audio result is weaker than the claim it tests. A silent oscillator may be treated by Chrome as "not audible", so our test may not exercise the exemption at all. That is exactly why we refuse to state a conclusion we cannot support.
Phones were not instrumented here. The phone-alarm section reflects the documented behaviour of native alarms versus third-party apps; we did not measure handsets for this piece.
Timestamps fix the reading, not the wake-up. Repeated because it is the whole point: correct elapsed-time maths does not guarantee an on-time alert.

Frequently asked questions

Can a web page reliably wake me up while I am in another tab?

No. The page can keep correct time, but the browser may not wake it on schedule, and mobile tabs are suspended even more aggressively. Treat a web alarm as a convenience, not a guarantee. Use your phone's built-in alarm for anything that matters.

Does silent mode stop my phone's alarm?

Usually not the built-in one — the Clock app's alarm sounds even with silent mode on, and Focus/Do Not Disturb do not block it by default. Silent mode does silence notifications, which is why third-party alarm apps and reminders are the ones that fail.

Why does a timer site ask me to tap before it can beep?

Because browsers block sound until you interact with the page. The tap unlocks audio; without it, the alarm tone is not allowed to play at all — and you have to tap again after any reload.

Does playing a sound stop the tab being throttled?

Our headless test found the first-tier clamp still applied with a silent oscillator playing, and headless has no audio device, so we will not claim otherwise. Chrome documents that audio exempts a tab from intensive throttling; trust that for the later tier only, and do not count on it for precise alerts.