What's the best screenshot interval for a self screen audit? Why 5 seconds beats 1 and 60

We get this question constantly: "what interval should I set?" The honest answer is that it depends on what you're auditing for, but after running all three at length, 5 seconds is the default we ship and the one we'd tell a friend to use. Here's the arithmetic behind that, and the cases where you'd want something else.

The three candidates, and what breaks at each extreme

Most screen-monitoring tools let you pick an interval anywhere from sub-second to several minutes. In practice almost everyone lands on one of three regimes:

• 1 second — near-continuous capture. Feels rigorous. Isn't, for this use case.
• 5 seconds — frequent enough to catch context switches, sparse enough to stay invisible in storage and review time.
• 60 seconds — a coarse sampling approach, borrowed from old-school time-tracking software.

Each has a failure mode. 1-second capture drowns you in near-duplicate frames and fills your disk. 60-second capture is so sparse it systematically misses the short, high-frequency behaviors that actually define a "leak" — the reflexive tab-check, the 40-second scroll, the notification-triggered detour. 5 seconds sits in the gap where you catch the behavior without capturing the sneeze.

The storage arithmetic

Assume a modest screenshot: a 1920×1080 capture, JPEG-compressed, averaging roughly 150 KB (this varies with content — a code editor compresses better than a busy dashboard, but 150 KB is a reasonable middle estimate we've measured across mixed workloads). Over an 8-hour workday, here's what each interval costs you:

The 1-second column is where most people quietly give up. 126 GB a month is a real line item on a laptop SSD, and it forces either aggressive pruning (which defeats the audit) or cloud upload (which most local-first users are explicitly trying to avoid). 5 seconds at ~25 GB/month is comfortably manageable with a rolling 30-60 day retention window and basic compression — the kind of thing a background free watcher can just handle without you thinking about it.

60 seconds looks great on a spreadsheet and terrible in practice, for reasons that have nothing to do with disk space.

Why 1 second fails: signal-to-noise, not storage

The deeper problem with 1-second capture isn't the gigabytes, it's that it doesn't actually improve your audit. Task-interruption studies consistently find that meaningful attention shifts — switching from writing to email, from a spreadsheet to a chat app — happen on the order of tens of seconds to minutes, not single seconds. A 1-second cadence captures many frames of the *same* activity in a row. You get redundancy, not resolution. This matters practically: if you're reviewing a day's captures (or having an AI brief summarize them), redundant near-identical frames don't add information, they add review time and dilute the signal your summarizer has to work with. You end up needing more aggressive deduplication logic downstream just to undo what the capture interval did to you upstream.

There's also a battery and CPU cost. Continuous 1-second screenshotting on a laptop is a measurable background load — encoding a full-resolution frame every second isn't free, and over a workday it shows up in fan noise and battery drain. For a tool meant to run invisibly in the background all day, that's disqualifying on its own.

Why 60 seconds fails: it misses the leaks by design

The case for 60-second sampling usually comes from legacy time-tracking tools built for a different job: proving that an employee was "at the computer," not diagnosing where an individual's own attention goes. For that older use case, coarse sampling is fine — you're checking presence, not behavior.

But most self-audits care about exactly the behaviors that live and die inside a 60-second window:

• Checking a phone notification's desktop mirror, then returning to work — 15-30 seconds, often invisible at 60s cadence.
• A reflexive tab-check (email, Slack, a news site) that resolves in under a minute.
• The gap between "meeting ends" and "next task starts," which is frequently the single biggest recoverable leak in a workday and is almost always under 90 seconds if it's a habit rather than a deliberate break.

At a 60-second interval, you have roughly a coin-flip chance of even landing a frame during a 30-second detour, and if you do, you get one static frame with no before/after to establish what actually happened. You can't distinguish "checked phone, came right back" from "genuinely got distracted for four minutes" — both might register as a single ambiguous frame or none at all. The audit becomes a guess dressed up as data.

Why 5 seconds is the sweet spot

At 5-second intervals, a 30-second interruption is captured as 5-6 frames — enough to establish a before/during/after sequence, sparse enough that it's not 30 redundant near-duplicates. This is the resolution where an automated daily brief can actually name something specific: "you opened a new tab 14 times between 2pm and 4pm, averaging 90 seconds each" is a sentence that requires roughly this cadence to construct honestly. Sparser, and you're extrapolating. Denser, and you're not gaining precision, just cost.

Five seconds also happens to align with a practical constraint: it's frequent enough to catch app-switch and window-focus events (which most operating systems can log natively, giving you a second data source to cross-check against the screenshots) without generating so much data that local search and review become sluggish. If you want the daily brief to actually be useful rather than a wall of thumbnails, the input cadence needs to match what a human or an LLM can meaningfully summarize — and 5 seconds is close to the finest grain that still compresses into a coherent narrative rather than a slideshow.

When to deviate from 5 seconds

5 seconds is a default, not a law. A few legitimate exceptions:

1. Deep, single-app focus work (writing, coding for long stretches) — 10-15 seconds is often plenty, since the "leak" you're hunting for is switching away, not micro-behavior within the app.
2. Diagnosing a specific fast-twitch habit (compulsive refresh-checking, rapid notification-chasing) — dropping to 2-3 seconds for a short, targeted audit window (an hour, not a month) can sharpen the picture without the storage cost of running it continuously.
3. Long-horizon, low-stakes background tracking — if you already know your leaks and just want a coarse monthly trend line, 30-60 seconds is fine and cheap.

If you're trying to figure out which of these applies to you, or want the interval to adjust automatically based on detected activity level rather than picking one number for the whole day, that's the kind of adaptive logic we cover in Pro — variable-rate capture that tightens up during ambiguous switching behavior and relaxes during clearly focused stretches, without you manually flipping a setting.

FAQ