Pomodoro Timer with Custom Intervals

What the technique actually asks of you

Francesco Cirillo wrote the method down in the late 1980s and named it after the tomato-shaped kitchen timer he used as a student. The famous part is the interval: 25 minutes of work, 5 minutes off, and a longer break after four rounds. The part almost everyone drops is the rule that makes the interval mean anything.

A pomodoro is indivisible. If you break off to answer a message, the pomodoro is void — you do not pause and resume, you start it again. That sounds pedantic until you see what it is for. It puts a visible price on every interruption, which is the only reason you ever start defending the time. The second discarded rule is the log: Cirillo has you write down what each interval produced, because the tally is what tells you whether your estimates bear any relation to reality.

The timer above will let you pause, because being dogmatic about someone else's method is not a feature. But if the technique is not working for you, the pause button is the first place to look.

Why this timer counts from the clock

The obvious way to build a countdown is to run setInterval every second and subtract one each time. It is wrong in a way you only notice at the end. A browser timer is scheduled for at least 1000 ms, never exactly that, and the error only ever runs one way — late. Over 25 minutes on a busy machine, a tick-counting timer quietly falls behind.

Then it gets worse. Browsers deliberately slow down timers in tabs you are not looking at, because a hundred idle tabs waking up every second is how laptops lose an afternoon of battery. A hidden tab has its timers clamped to roughly once a second, and Chrome goes further: after a tab has been hidden for about five minutes, its timers can be cut back to around once a minute. A countdown that counts its own ticks does not run slow in a background tab. It very nearly stops.

So this one records the wall-clock moment the session ends and, on every redraw, asks how much is left. Ticks can be late, dropped or delivered in a clump; the number on screen is still correct, because nothing was ever being accumulated. Leave the tab for twenty minutes and the display is right the instant you come back.

What that does not fix

• The chime can be late. The countdown is accurate, but the code that plays the sound still has to be given a turn to run. In a throttled background tab the alarm can arrive up to a minute after the session actually ended. If the exact moment matters, keep the tab visible.
• A sleeping device stops everything. Shut the laptop lid or let your phone lock the screen and no code runs at all. When you come back the timer shows the session finished, having never made a sound.
• The chime needs a click first. Browsers block audio until you interact with the page, so the sound is prepared when you first press Start. Turn the chime on mid-session and it will be silent until the next time you press Start.
• Nothing survives a reload. Your lengths, your session count and the timer itself live in memory only. There are no desktop notifications either — this tool never asks for that permission, so a fully hidden window will not interrupt you.

Choosing intervals that fit the work

Twenty-five minutes is not a research finding. It is a default that suited a student with a kitchen timer, and treating it as sacred is the most common way people bounce off the method. Two things are worth knowing when you change it.

Work with a long ramp-up — debugging, anything where you have to reload a lot of context into your head — pays that loading cost every time you stop. If it takes ten minutes to get the problem back in view, a 25-minute session spends nearly half of itself on setup, and blocks of 45 to 90 minutes serve it better. Shallow work is the opposite case: email, forms, the chore you have been avoiding. There the enemy is starting, not stopping, and a short interval works precisely because 15 minutes is too small a commitment to argue with.

Adjust the break with the same honesty. A break spent on the same screen reading the same kind of text is not a break. Stand up, look at something further than an arm away, get water.

When the timer is not the problem

Evidence for the specific 25/5 split is thin, and anyone quoting a precise productivity percentage at you is making it up. What is defensible is the mechanism: a bounded commitment is easier to start than an open-ended one, and a scheduled stop is what keeps you from working past the point of usefulness. Neither of those requires 25 minutes exactly.

It also cannot compete with a phone. A timer enforces a boundary you have already decided on; it does nothing about notifications, an open chat window or a tab you keep flicking back to. Put the phone in a drawer, close the mail client, then start the timer. In that order.

Last updated September 19, 2026