Focus Session Log

Time a block of real work, and write down every time something pulls you out of it. After three or four sessions you stop guessing about where your attention goes and start looking at a number. Most students are surprised by which column is bigger.

How to use this tool
  1. Name the thing you are about to work on, set a target length, and press Start.
  2. Every time your attention leaves the work — for any reason, including your own — press Log an interruption, pick the source, and put a rough number on the minutes it cost you. Log it as it happens, not from memory afterwards.
  3. Pause stops the clock if you genuinely stop working. End session files it into the history table.
  4. The clock keeps counting past your target. Reaching the target is information, not a bell.
  5. Read the numbers after three or four sessions, not after one.

Honest logging beats tidy logging. A session with nine interruptions recorded is more useful than a session with two recorded and seven forgotten. Nobody else sees this.

The ticking clock is deliberately not announced by screen readers — it would talk over everything else. Start, pause, end and target-reached are announced, and the current elapsed time is readable at any moment from the "Elapsed time" text that follows the timer.

How this maps to Jira and similar trackers
HereAt workWhat you would actually hear
Focus sessionFocus time / deep work block"I've blocked two hours tomorrow morning for the migration."
Target lengthTimebox"Timebox it to an hour and come back with whatever you have."
External interruptionInterrupt work / interrupt load"Who's on interrupts this sprint?"
Not being interruptibleDo not disturb, status, async norms"Heads-down till 2 — put it in the ticket and I'll pick it up."
A fragmented dayCalendar fragmentation, maker vs. manager schedule"My calendar is swiss cheese, I got nothing built today."

Teams that take this seriously protect focus deliberately: no-meeting days, a rotating "interrupt duty" engineer who absorbs questions so everyone else is left alone, a norm that a message is not an interrupt because nobody is expected to answer it within the hour. That last one is what "async" actually means in practice — it is a promise about response time, not a tool choice.

Why meeting-heavy days hurt engineering output more than they hurt other work: an hour with three thirty-minute gaps in it is not an hour of building. Each gap costs the reload described further down the page, so four scattered meetings can flatten a day that had six nominally free hours in it. Managers whose work is mostly conversations often do not feel this, which is why you may have to say it out loud.

Be honest about the disagreement. Some teams measure focus time with calendar analytics or a cycle-time report in Jira; most measure nothing and run on norms. Plenty of experienced engineers think tracking interruptions is surveillance-adjacent and refuse. On a support-heavy or on-call team, being unreachable for two hours is a real cost to someone else, and "do not disturb" is a negotiation rather than a right. The tool here is for you, about you, and stays on your machine — that is the version of this that is uncontroversial.

This session

Name the actual work, not the course. "CS 240" tells you nothing later; "trace the segfault to the free() call" tells you what kind of concentration it needed.

Timer

Not started.

No session running. Name the work, set a target, then press Start.

Interruptions in this session

Log an interruption
Started by me
Started by something else

The button turns on once a session is running.

Nothing logged in this session yet.

Session history

Completed focus sessions, oldest first
Date Task Planned Focused Interruptions Self External Longest run Delete

"Focused" is the elapsed time minus the minutes you said each interruption cost you. "Longest run" is the biggest gap between one interruption and the next.

What the log says

Finish a session or two and observations will appear here.

Why an interruption costs more than it lasts

An interruption is not as long as the interruption. When you stop mid-debug you lose the state you were holding: which branch you were on, which two values disagreed, the hypothesis you were three steps into testing. None of that is written down, because holding it in your head is what was making you fast. Coming back means rebuilding it from the artefacts — rereading the trace, re-deriving the step, remembering which lemma you had already used. That rebuild is the real cost, and it is much the same whether you were gone for thirty seconds or ten minutes. Budget the reload, not the interruption.

One more question

Keep your work

This tool remembers your work in this browser on this device. Nothing is sent anywhere.

Autosave is on.