Autosave interval trades data safety against cost
Aliases: autosave frequency · save interval · loss window · write budget
What it is
How often autosave fires decides two things at once: how much can vanish in a crash, and how much the system pays all the time. Interval choice treats that clock as an explicit trade: shorter intervals shrink the unsaved window and raise the bill for writes, sync, conflict checks, and battery; longer intervals cheapen the bill and enlarge how much an interruption can swallow. Whether a long form should keep a draft at all is a different question. Here the draft is already being written; the only issue is how fast the clock should run.
Why it happens
The unsaved window averages about half the interval — a crash in the middle of a cycle loses half a period of keys. Tightening thirty seconds to three shrinks the window by an order of magnitude and raises write count by the same. Cost is not one disk write: a server-side draft spends bandwidth and versions; each write can meet someone else’s write; on a phone, periodic radio wake-ups spend battery. One layer down, writes that are too dense become foreground work: input hits locks, caret jumps, IME redraws. Safety was bought with stutter.
Safety also tracks how irreplaceable the content is. A long passage that is hard to retype, an application filled past the midpoint, loses more subjectively in the same thirty-second window than flipping a switch. Frequency should not be one product-wide number; it should split on “cost of loss / cost of one write”.
Where it stops holding
Read-only review, a successful submit, content that barely changes: high-frequency writes make noise and overwrite risk, and should drop toward zero or stop. A local unsigned draft, however dense, does not survive a device switch — that safety lives in account-side sync and cannot be patched by shrinking the local interval further. In a collaborative document, overly dense autosaves turn every pause into a conflict candidate; that needs a merge policy, not interval as the only knob. On battery-sensitive or metered networks the cost term can dominate data safety; write “on change and after a minimum interval”, not a metronome that ticks on idle.
Applying it
- Band by irreplaceability: short fields can wait longer or write on blur; long prose and multi-step applications use a shorter interval, and write only when there is a change, so idle does not spin.
- Watch two quantities together: editable duration that a crash can erase, and writes plus traffic per unit time. Optimising only one shoves the other into the unacceptable.
- Local and server writes may run at different rates: dense local, sparse remote — crash recovery from local, device switch from remote.
- How to check: kill the process halfway between two saves and confirm loss stays inside the chosen window; count actual writes in that minute. Shrink the interval toward every keystroke; obvious typing stutter means cost has overtaken safety. Stretch it to minutes, fill a long passage, kill the process; the loss should be judged unacceptable.