Two different features get called autosave and they behave differently, and people are surprised by both.
AutoRecover is the local one. It writes a recovery copy at an interval, ten minutes by default, and offers it back after a crash. It isn't a save. The recovery copy disappears once you close the file normally, and it recovers to the last interval, so the keystrokes since then are gone. AutoSave is the cloud one. It applies to files stored in a synchronised location, writes continuously, and keeps a version history you can roll back through. Both the default interval and the exact behaviour of the two features move between releases (checked September 2026; confirm in your own installation, and confirm where your organisation actually stores files, because AutoSave does nothing for a file on a local drive).
How much work does a crash cost?
Now model the exposure. If a crash arrives uniformly at random between saves, the expected work lost is half the interval: 5.0 minutes at a ten-minute interval, 2.5 at five minutes, 1.0 at two. Now apply a crash rate. A six-hour build at one crash per nine editing hours has 0.6667 expected crashes, so the expected loss over the whole build is 3.3333 minutes at a ten-minute interval, 1.6667 at five and 0.6667 at two. Tightening from ten minutes to two saves 2.6667 expected minutes across an entire deck.
Read that number carefully, because it argues against the thing it looks like it argues for. Two and a half minutes isn't why you save. The expected value is small and the variance is what hurts. The average isn't the quantity to plan against. The tail is, where a crash lands twenty minutes into a restructure you can't reconstruct from memory. That's a versioning problem, and no interval solves it. A milestone copy does, made before any structural change and named with the date and version so it sorts where it belongs.
Advertisement
What can you do when a file won't open?
When a file won't open, you've got three moves, in order. Use the application's own open-and-repair option, which recovers the majority of damaged files. Try opening the file in a different application, because a competing renderer is often more forgiving about the specific part that is corrupt. And if both fail, treat the file as what it physically is. A modern PowerPoint file is a zip container holding XML parts and a media folder. Rename a copy to a zip extension, open it, and you recover the images, the embedded video and often the raw slide text even when the deck itself won't load. Work on a copy, always, because the archive route is a salvage operation and not a repair.