The one-week time audit: a day-by-day plan from first capture to first fixed leak

Most people who try to fix their time use don't fail because they lack discipline. They fail because they skip the audit and go straight to the intervention — blocking apps, deleting icons, installing a "focus mode" — based on a guess about where the time goes. The guess is usually wrong by 30-50%. We've looked at enough before/after logs to say that with some confidence: the app people swear is "eating their whole day" is rarely the top-three time leak once you actually measure it.

This is a seven-day plan. Day 1-3 is pure capture, no changes. Day 4 is analysis. Day 5-7 is one fix, tested, not five fixes guessed at. That order matters more than any individual tool you use.

Day 0: set up capture, change nothing

Install a passive tracker before you do anything else. The requirement is that it logs automatically — no manual start/stop, no "I'll remember to note it." Manual time logs undercount interruptions by roughly 40-60% in self-report studies, because the switch itself is the thing you forget to log. If you want a local-first option that just runs in the background and keeps the data on your machine, the free watcher is built for exactly this baseline week — nothing to configure, nothing shipped off-device.

Two rules for day 0:

• Don't change behavior. This is the week you'd have anyway. If you block Twitter on day 1 you've measured your willpower, not your baseline.
• Don't peek at dashboards. Checking your live time-spent number mid-week changes the number. Wait for day 4.

Days 1-3: capture, with one manual layer

The tracker gives you duration and app/window titles. That's necessary but not sufficient — it can't tell you why you opened something. So for these three days, add one manual habit: every time you notice you've context-switched without meaning to, jot a two-word tag (bored / stuck / notification / habit). You'll get maybe 15-25 of these a day. It's a sample, not a census, and that's fine — you're triangulating causes, not building a perfect log.

Task-interruption studies consistently find that recovery from a context switch takes longer than the switch itself — commonly cited ranges run from 5 to 25 minutes to fully re-establish the prior train of thought, depending on task complexity. That's the number that makes a 90-second Slack check cost far more than 90 seconds, and it's the number your raw duration log will never show you on its own. The tags are how you catch it.

Day 4: read the data before you touch anything

Pull three numbers, in this order:

1. Total screen time — the headline number, mostly useless on its own.
2. Switch count — how many times you moved between apps or windows. This correlates with felt exhaustion more tightly than total time does.
3. Top 5 leaks by time × switch frequency — not top 5 by time alone. An app you use for 90 focused minutes once is not a leak. An app you touch 40 times for 90 seconds each is, even though the raw totals look similar.

Here's a worked example from a real three-day capture (identifying details changed, arithmetic is real):

Video streaming has the highest raw total — 4h 05m over three days — and it's the one this person assumed was the problem going in. But it's four sessions, low switching, genuinely intentional watching. The messaging app has less than half that raw time, but 47 switches at an estimated 10 minutes of recovery cost each works out to a theoretical 7h 50m of disrupted attention over three days — more than triple its logged screen time. That's the leak. It was invisible in the "total time per app" view and obvious the moment switch count entered the table.

The 10-minutes-per-switch figure is a mid-range estimate, not a universal constant — real recovery cost depends on task complexity and how deep you were when interrupted. Use it as a multiplier to rank leaks against each other, not as a literal number you report to your boss.

Day 5: pick exactly one leak

Resist the urge to fix all five things on your top-5 list. A week that starts with five interventions ends with zero measured, because you can't attribute the change in day 7's numbers to any one of them. Pick the leak with the highest switch-frequency × estimated-recovery-cost score, and fix the mechanism, not the willpower.

Mechanical fixes that actually hold, roughly in order of how little discipline they require:

• Remove the trigger. Turn off push notifications for the specific app, not "do not disturb" generally. Notification-driven switches are the easiest category to kill outright because you're not fighting a habit, you're removing the cue.
• Batch the checks. If it's a messaging app, move it off the home screen and set two or three fixed windows a day to check it. Going from 47 unplanned switches to 3 planned ones doesn't reduce total messaging time much — it reduces the recovery-cost multiplier by roughly 15x.
• Add friction, not willpower. Log out instead of staying signed in. Move the icon a folder deep. The goal is one extra deliberate step between impulse and open, not a blanket ban you'll override in a week.

Write down the specific change and the time you made it. You need that timestamp for day 7's comparison.

Days 6-7: run the fix, keep measuring

Same passive capture as days 1-3, same rules — don't add a second fix mid-test, don't peek and adjust. Two days is short, so don't expect a clean before/after on total screen time; do expect a visible change in switch count for the specific app you targeted. That's the number that moves fastest and most reliably.

If switch count on the target app hasn't dropped by day 7, the fix addressed the wrong mechanism — often people block an app but leave the notification on for its web version, or restrict phone use while the same habit runs uninterrupted on desktop. That's diagnostic information, not failure: it tells you where the actual trigger lives.

What one week actually gets you

A week isn't enough to change a habit permanently — most behavior-change estimates run 3 to 8 weeks for a new pattern to stick without active monitoring. What one week gets you is a baseline that replaces guessing, and one fix that's been tested against your own data instead of a generic productivity article. That's a defensible starting point, which is worth more than five untested changes made on day one.

If the week convinces you the leak-naming and multi-day pattern tracking is worth keeping running rather than doing by hand every time, that's what the automated daily brief in Pro is for — same switch-frequency logic, run continuously instead of manually on day 4.

FAQ