A five-second undo window fits a typo; a mistaken transfer needs far longer

What it is

An undo window is the stretch of time after an action completes during which a user can still take it back. This entry is about how long that stretch should be: it shouldn't be one number used across the whole product (a flat 5 seconds, or a flat 24 hours) — it should be tiered by how severe each action's consequence is, with a short window for low-stakes actions and a much longer one, sometimes paired with an active notification, for actions with serious or long-delayed consequences.

Why it happens

Whether an undo window actually works depends on whether the moment the user realizes they need to undo falls inside the window — not on how much fixed time has passed since the action happened. For minor actions (archiving an email, muting a notification), if the user hasn't reacted within a few seconds, that's usually a good sign the action really was what they wanted, and a short window already covers nearly every real moment of hesitation. But for actions with serious or slow-to-surface consequences — canceling a subscription, deleting an account, removing a file that won't be opened again for a long time — the moment a user realizes "that's not actually what I wanted" can come much later than the action itself: maybe days later, prompted by a renewal reminder, or weeks later when they go looking for that file and realize it's gone. If the window is set to the same short duration used everywhere else, it closes long before the user has any chance to notice the problem, which makes having a window at all meaningless.

Where it stops holding

This principle doesn't apply once the action, during the window, has already produced an external effect that can't be pulled back internally — no matter how long the window is, if the effect already crossed the system's boundary the instant the action happened (a message already read, funds already landed in someone else's account), window length can't undo an effect that's out in the world. What matters there is whether any remedy is possible at all, not how the window should be sized.

Applying it

Group undoable actions in the product into explicit tiers by consequence severity rather than picking a number for each one individually: minor, high-frequency actions get an immediate toast-style undo lasting a few seconds to under a minute; moderate-consequence actions get a recoverable period of days to a month (a trash or recycle bin); actions with serious consequences, or ones a user is likely to notice only much later, get a longer grace period paired with an active reminder — a notice before a subscription actually cancels, a confirmation email before an account is actually deactivated — rather than leaving it to the user to remember to check. The basis for picking that duration should be "how long, on average, does it take a user to realize this action was a mistake," not whatever default value some other feature happens to already use. Verification: for each category of undoable action, track the distribution of when users actually click undo. If a meaningful share of undo requests arrive after the window has already closed (users contacting support asking to be restored), the window is too short and doesn't cover the real discovery delay — recalibrate its length against that distribution.

Related

• Same group: A10.08.2 undo before confirmation · A10.08.6 a checklist for identifying irreversible actions · A10.08.1 fault tolerance — the system stays recoverable after an error occurs
• Nearby: A11.03 interaction adaptations for older users
• Search terms: undo window · grace period · recoverable deletion