iKit
Productivity · 10 min read ·

Pomodoro Technique in 2026: Why 25/5 Still Works Best

The Pomodoro Technique explained for 2026: where 25/5 came from, what break research actually shows, and how to run a drift-free timer in your browser.

Pomodoro Technique in 2026: Why 25/5 Still Works Best

Pomodoro Technique in 2026: Why 25/5 Still Works Best

You open a task, work for four minutes, check Slack, come back, and forty minutes have vanished. The Pomodoro Technique fixes that with one rule: a fixed block of time in which you do one thing. It is thirty-five years old, survived every productivity fad since, and the reason is not the number 25 — it is what a fixed unit does to your estimates.

TL;DR

  • One pomodoro = 25 minutes on one task, then a 5-minute break.
  • After four pomodoros, take a 15–30 minute break.
  • The 25 is arbitrary; keeping it fixed is what makes it useful.
  • Research supports short breaks for fatigue, not for raw output.
  • Browsers throttle background timers — store end times, not ticks.

What is the Pomodoro Technique?

It is a time-management method built around a countdown timer and one non-negotiable rule: while the timer runs, you work on one task and nothing else.

Where the 25-minute pomodoro came from

Francesco Cirillo created it in the 1980s as a university student who could not concentrate, using a tomato-shaped kitchen timer — pomodoro is Italian for tomato. On his own account of the method's origin, the first experiment was not 25 minutes at all but a question: could he study for two minutes without interruption? The 25-minute block is where that experiment settled.

That history matters because it kills the most common objection. Nobody measured 84 subjects and derived 25 as the optimum. It is a length short enough that starting does not feel like a commitment, and long enough that you reach something by the end.

The five steps, in order

  1. Pick one task. Not a project — a task you could finish or clearly advance.
  2. Set the timer to 25 minutes.
  3. Work until it rings. No tab-switching, no "quick check."
  4. Mark the pomodoro as done and take a 5-minute break.
  5. After four pomodoros, take a longer break of 15–30 minutes.

The marking step looks like bookkeeping busywork and is the step most people drop. It is also the one that turns the technique from a timer into a method — see the estimation section below.

What Cirillo says the technique is not

Cirillo is blunt that the popular version — "work 25, break 5" — is a compression of a much larger system that also covers daily planning, effort estimation, and interruption protocols. He is equally blunt about what productivity means:

"true productivity means working less while achieving the same results."

— Francesco Cirillo

He also rejects the pomodoro-count-as-score habit outright: the goal is not to complete pomodoros, it is to become aware of where your attention actually goes.

Why does the Pomodoro Technique work?

Three separate effects are doing the work, and only one of them is about the break.

What the vigilance-decrement research shows

Attention on a long, unchanging task degrades — the "vigilance decrement." The standard explanation for decades was that attention is a finite resource that drains. A 2011 study in Cognition by Atsunori Ariga and Alejandro Lleras argued the opposite: attention does not run out, it habituates, the same way you stop feeling your clothes against your skin.

Their experiment ran 84 participants through a repetitive 50-minute task. The University of Illinois summary of the study reports that the group given two brief, unrelated diversions mid-task showed no measurable decline in performance, while the control group's performance fell off as expected. Lleras's practical conclusion was to impose brief breaks on yourself during long tasks.

A pomodoro break is exactly that imposition — scheduled, so you do not have to notice you are fading before you take one.

Do micro-breaks actually improve performance?

Partly. The 2022 PLOS ONE meta-analysis "Give me a break!" pooled 22 studies of micro-breaks — pauses of ten minutes or less. Micro-breaks reliably reduced fatigue and increased vigor. The effect on task performance was weaker and depended on how demanding the task was; longer breaks helped more when the work was harder.

Read honestly, that says a 5-minute break is well-supported as fatigue management and only weakly supported as an output booster. Which is the right way to sell it: the technique lets you work a full day without ending it fried, not finish twice the work by 11am.

Why interruption is the real enemy

The single-task rule may matter more than the break. In the CHI 2008 study The Cost of Interrupted Work, Gloria Mark and colleagues found interrupted participants completed tasks faster than uninterrupted ones — but paid for it with higher workload, more stress, more frustration, and more time pressure. Speed bought by interruption is speed bought on credit.

A pomodoro is a 25-minute window in which interruption is against the rules. That constraint is doing more work than the timer is.

How long should a Pomodoro be — 25, 50, or 90 minutes?

The honest answer: pick based on the task's warm-up cost, then stop changing it.

Interval Break Best for Watch out for
15 / 3 3 min Tasks you dread starting Too short for anything with setup
25 / 5 5 min Default; mixed work, triage, review Cuts across deep debugging
50 / 10 10 min Writing, debugging, design Easy to skip the break entirely
90 / 20 20 min Single-block deep work Fatigue arrives before the bell

When 25/5 is the right default

Use 25/5 when the work is made of small units, or when the hard part is starting. Code review, inbox triage, test writing, admin — all have near-zero warm-up cost, so a short block loses you nothing and the frequent finish line keeps you moving.

When to stretch to 50/10

Use a longer block when re-entry is expensive. Reconstructing a bug's mental state or getting back into the shape of an argument can eat five of twenty-five minutes. If your first observation every block is "where was I," the block is too short.

Note that the meta-analysis nuance points the same way: harder tasks benefited more from longer breaks. Scale both halves, not just the work half.

Why you shouldn't change the ratio every day

Here is the part almost every app gets wrong by making the interval a slider. A pomodoro is a unit of measurement. Its value comes from being constant:

  • "This migration took 6 pomodoros" is only meaningful if a pomodoro is always the same length.
  • After two weeks you can estimate in pomodoros before starting, then compare estimate to actual.
  • That comparison — not the timer — is what makes you better at planning.

Change the interval daily and you have a stopwatch with extra steps. Change it once, deliberately, and keep it for a month.

How to run a Pomodoro timer in your browser

A browser tab is the natural home for this: nothing to install, and no reason for a countdown to talk to a server. The iKit Stopwatch & Timer runs the whole thing client-side, and for a date-based target — a deadline rather than an interval — the countdown timer is the better fit. Neither sends your session anywhere.

Why your timer loses time in a background tab

Because browsers deliberately slow down timers in hidden tabs to save battery. Per MDN's documentation of setTimeout(), Chrome's minimum delay in a background tab is about 10,000 ms — ten seconds — kicking in roughly 30 seconds after the document loads, versus a 4 ms floor in the foreground. Firefox desktop clamps inactive tabs to a 1-second minimum.

So a timer written like this loses minutes:

// Broken: assumes the tick fires on time
let left = 25 * 60;
setInterval(() => {
  left -= 1;          // one "second" that
  render(left);       // may be 10s apart
}, 1000);

Every throttled tick subtracts one second from a gap that was really ten. Come back after twenty minutes in another tab and the display insists you have twenty-two minutes left.

Building a drift-free countdown

Store the moment the pomodoro ends, then derive the remaining time from the clock on every render. The tick rate becomes irrelevant:

const DURATION = 25 * 60 * 1000;
const endAt = Date.now() + DURATION;

function remaining() {
  return Math.max(0, endAt - Date.now());
}

setInterval(() => {
  const ms = remaining();
  render(ms);
  if (ms === 0) ring();
}, 250);

The interval now only drives repaints. Whether it fires four times a second or once every ten seconds, remaining() returns the truth, because it asks the system clock rather than counting its own heartbeats.

Notifications and sound without an app

Two more pieces make it usable when the tab is not in front of you:

  • Re-render immediately on visibilitychange so the number is correct the instant you look at it.
  • Fire a Notification at zero, and play a short tone — audio playback also exempts the tab from some throttling while it is sounding.
document.addEventListener("visibilitychange", () => {
  if (!document.hidden) render(remaining());
});

That is the whole engineering problem. Everything else is presentation.

Pomodoro Technique mistakes that quietly kill it

Counting pomodoros as a score

Eight pomodoros of shuffling a document is worse than three that shipped something. Cirillo's own answer to "how many should I do?" is that even one, or none, is fine. The count is diagnostic data about where your attention went, not a leaderboard.

Filling the break with your phone

A break spent scrolling is not a deactivation of the task goal, it is a substitution of one demanding visual task for another. Ariga and Lleras's diversions were brief and unrelated; the useful five minutes is the one where you stand up and look at something further than 60 cm away.

Splitting a pomodoro

The original rule is that a pomodoro is indivisible: interrupt it and it does not count. That sounds punitive until you notice what it is really for — it makes the cost of a "quick check" visible. If a colleague costs you a pomodoro, you now have a number for that instead of a vague sense of a fragmented day.

What to do this week

Run 25/5 for five working days without tuning anything. The interval is not the experiment — the gap between your estimate and reality is.

Log the estimate and the actual

Two minutes at the end of the day: task, pomodoros estimated, pomodoros actual. That's it. If you draft in Markdown, keeping the log in a Markdown editor alongside your notes is enough; if you are tracking writing output, a word counter turns "three pomodoros" into "three pomodoros, 900 words" and gives you a rate you can plan with.

Compare on Friday, then change one thing

At the end of the week, look at where estimate and actual diverged most. Usually it is one category of work — the thing you consistently under-price. Adjust that estimate, not the interval, and run another week. That gap closing is the entire return on the technique.

References

Related on iKit

Related posts