How to protect deep work blocks using your own screen data (not calendar theory)

You blocked 9–11am. It's on the calendar, colored purple, labeled "deep work." And yet by 10:40 you've context-switched four times, answered two Slack messages you told yourself you'd ignore, and opened a browser tab "just to check one thing" that turned into eleven minutes on a news site. The block existed. The deep work didn't.

This is the gap between calendar theory and screen reality. Calendar blocking assumes the constraint is scheduling — that if you carve out the time, focus follows. But most deep work failures aren't scheduling failures. They're mechanical failures: specific apps, specific triggers, specific minutes where attention leaks out through a hole you haven't looked at directly. You can't patch a hole you haven't measured.

Why the calendar can't see the leak

A calendar block is a claim about intention. It says "this time is reserved." It says nothing about what actually happened inside it. If you want to know why a block failed, the calendar has zero data — you have to go to the thing that was actually running on your screen, second by second, and look at where the attention went.

Task-interruption studies consistently find that recovery from a context switch isn't instant — there's a resumption cost measured in minutes, not seconds, and the cost compounds with the complexity of the interrupted task. So the real damage of a "quick check" isn't the 90 seconds it visibly took. It's the 6-12 minutes of degraded output on either side of it while your brain reloads context. A block interrupted four times isn't a block that lost four checks. It's a block that lost most of its value.

What screen data actually shows, mechanically

When you log actual foreground-app time during a supposed deep work block, three patterns show up over and over:

• The pre-block leak. The 5-10 minutes before the block starts are spent "getting settled" — email, Slack, a tab check — which means the block doesn't start at 9:00, it starts at 9:09, already interrupted once.
• The notification-shaped hole. A specific app (usually chat or email) gets foregrounded at a near-constant interval — every 12-20 minutes — regardless of what you're working on. This isn't willpower failure. It's a trained reflex to a badge or a sound.
• The tail drift. The last 15-20 minutes of the block quietly become browsing, because the "hard part" of the task got finished (or avoided) and nothing was scheduled to replace it.

None of these show up in a calendar audit. All three show up immediately in raw screen-time logs, because the logs don't care what you intended — they only record what ran.

The arithmetic: what a "protected" block actually costs

Here's a real-shape example — a 2-hour block, logged at 1-minute resolution, from a fairly typical case we see in local logs (an app-switch tracked as "foreground change," not just a tab click):

Add it up: of 120 scheduled minutes, only 66 were actually spent on the work, interruptions themselves cost 14 minutes of visible time, and resumption cost — the invisible tax — adds another 22 minutes of degraded reload time layered on top of the remaining "focus" minutes. Roughly speaking, this block delivered under 45% of its nominal value. The calendar would report a 100% success rate: block scheduled, block occupied by no external meeting. The screen data reports something closer to a 44% deep-work yield.

This is the number that matters, and it's the number calendar theory structurally cannot produce.

Fixing the leak mechanically, not motivationally

Once you can see where a block actually breaks, the fixes are boring and specific — which is exactly why they work. Each pattern above maps to a mechanical intervention, not a willpower instruction:

1. Pre-block leak → hard start rule. If logs show settling-in time before 80%+ of your blocks, the fix is a fixed pre-block routine (close email, close chat, open only the working file) done at a set time before the block, not during it.
2. Notification-shaped hole → close the app, not the tab. If a chat app gets foregrounded every 12-20 minutes regardless of content, muting notifications doesn't fix it — the habit is now decoupled from the trigger. Quitting the app for the block duration does, because there's no icon to reflexively click.
3. Tail drift → schedule the next concrete action. If the last 15-20 minutes consistently drift, the block is too long for the task or the next task isn't defined. Shortening the block to match observed sustained-focus length (33 minutes in the example above, not 120) removes the empty tail entirely.

Notice none of these are "try harder" or "want it more." They're structural: a routine, an app-quit, a shorter block. Mechanical fixes for mechanical failures.

How to actually check yours

You don't need a theory of your attention. You need a log. The minimum viable setup: passive foreground-app tracking during your next five attempted deep work blocks, then look at three numbers — minutes before first interruption, interruption count, and tail-drift length. If you don't have a tracker running, a free local-first watcher like the one at /download gives you exactly this without sending anything off your machine, which matters because the data is, by definition, a log of everything you do.

The three-number check above is manual and takes a few minutes per block. If you want the pattern-matching done automatically — leaks named, mechanical fixes suggested, without you eyeballing timestamps every morning — that's the actual job of the daily brief; see /pro for how it's built.

What "protected" should mean

A protected block isn't one where nothing was scheduled over it. It's one where the yield — actual focused minutes divided by scheduled minutes, net of resumption cost — stays above some number you've decided is acceptable, say 75-85%. That number comes from measurement, not intention. Calendar blocking gets you the opportunity for deep work. Only screen data tells you whether you took it.

FAQ