About Timerly
Timerly is a countdown timer built around one complaint: you set a timer in a browser tab, switch to something else, come back, and the number on screen is wrong. Not slightly wrong — visibly, annoyingly wrong, in a way that makes the whole tool untrustworthy. Everything on this site follows from fixing that properly instead of papering over it.
The one design decision
When you press start, the page records a single number: the instant your timer is due to finish, as
milliseconds on the browser's monotonic clock — performance.now(), not
Date.now(). That distinction is small and it is not cosmetic: the wall clock can be
moved by a network time correction or by you changing the system time, and a deadline pinned to it
would move with it. A monotonic clock only ever runs forwards at one rate. Every animation frame
after that does one thing — subtract the current clock reading from that instant. The remaining time
is therefore derived, never accumulated.
That sounds like a small detail and it is the whole product. A timer that adds up ticks is a timer whose accuracy depends on every one of those ticks arriving, and on arriving on time. A timer that subtracts from a fixed instant does not care how many samples it missed, how late they were, or whether the tab was frozen for three seconds in the middle: the next sample re-derives the answer from scratch and is immediately correct.
We did not want to simply assert that this matters, so we measured it. The method, the four runs and the resulting per-length table are published on the home page, and the script that produced them ships in the repository. It writes its results directly into the module the pages render from, so nothing on this site is a hand-typed number that could quietly stop matching the measurement that justified it.
The alarm
The second half of the problem is the sound. Most web timers play their alarm from JavaScript at the moment the countdown notices it has reached zero — which is precisely the thing a backgrounded, throttled tab is unreliable at. Timerly instead books the alarm on the browser's audio clock when the timer starts. The tones are queued before the tab is ever hidden, and audio that has already been scheduled is not subject to script throttling.
That is a real improvement and it is not a guarantee, so here is the part most pages leave out. The
exemption a browser grants to audio is an exemption for audio that is audible. A timer
waiting out twenty minutes is silent for all twenty of them, and a silent context is exactly what
browsers feel free to suspend: WebKit suspends an AudioContext on visibility change
unless it is producing audio, Chrome's throttling exemption for a page that has "made noises"
explicitly does not count a silent audio track, and the Web Audio API now has an
interrupted state for precisely this — a pause the browser decides on, not the page.
While a context is suspended its currentTime stops advancing, so a booked alarm is
delayed and not lost: it tends to arrive when you come back to the tab. The correct
summary is that booking the alarm removes one failure mode (a throttled script never noticing zero)
and does not remove the other. For anything with a consequence attached, use a device alarm too.
The sound itself is four short tones generated from oscillators — a sine at 880 Hz with a quieter octave above it, shaped by a fast attack and an exponential decay. There is no audio file, so there is nothing to download, nothing to fail, and no request made when your alarm goes off.
Two limits are worth stating plainly. Browsers do not allow a page to make any sound until you have interacted with it, so the alarm is armed by your first click on Start; the tool says on screen whether sound is ready yet. And a tab you have muted in the browser stays muted no matter how carefully the sound was scheduled.
What the site does not do
- It does not survive a closed tab. There is no storage and no notification. Close the page and the timer is gone; reopening gives you a fresh one.
- It does not survive a sleeping computer. Nothing in a browser tab runs while the machine is asleep. For anything with consequences — a train, a shift, an appointment — use a device alarm.
- It does not know anything about you. No account, no sign-up, no history. The durations you set are never transmitted anywhere; see the privacy page.
- It does not go past 24 hours. Longer values are rejected outright, never silently clamped into something you did not ask for.
- It is not an interval trainer. One countdown at a time, plus the fixed 25/5 alternation on the Pomodoro page. Configurable interval sequences are a different tool and adding them would make this one worse.
How the measurements were made
Four conditions, all on Node v22.20.0 on win32 10.0.26200 (AMD Ryzen 9 9950X3D 16-Core Processor), on
2026-08-14: sixty seconds idle, sixty seconds with the thread deliberately kept
busy, five minutes idle as a linearity check, and fifteen seconds containing one three-second
freeze. In each run a naive setInterval(1000) tick counter and a 16 ms-sampled
timestamp counter ran side by side against the same monotonic clock, and the moment each first
displayed every whole second was recorded.
Each condition was run 5 times, interleaved with the others, and what the site publishes is the median of those runs with the observed range next to it. That is a correction to an earlier version, which published one run per condition to four significant figures; re-running it showed the spread between repeats to be comparable to the difference between the conditions, which makes a single run an anecdote rather than a measurement. The raw runs are all kept in the generated data file, so nothing here rests on our summary of them.
The honest caveats, which the home page repeats next to the tables and every duration page now repeats next to its own: these are Node measurements on one desktop machine, not browser measurements across a fleet. The underlying behaviour is shared — a repeating timer is re-armed after each firing, and firings missed during a block are coalesced and never replayed — but the exact per-tick figures depend on the engine, the operating system and how busy the machine is. Every number on this site that is a projection is labelled as one, including in a dedicated column of every duration page's table, which also distinguishes arithmetic performed on a measurement from the measurement itself.
Who made it
One person, alongside other work, as part of a small set of single-purpose browser tools. There is no company behind it and no plan to add accounts, syncing or a mobile app. If something is wrong — particularly a number that disagrees with another number — the contact page is the place to say so, and that class of report gets priority over feature requests.