Autosave

The default interval is 60 seconds, set by the AUTOSAVE_INTERVAL constant in wp-config.php. The editor sends the title, content, and excerpt to the server; on a published post that creates a single autosave row in wp_posts with post_type revision and a post_name ending in -autosave-v1. There is only one per user per post, overwritten each time.

To see it, query SELECT ID, post_author, post_modified FROM wp_posts WHERE post_name LIKE '%autosave%' AND post_parent = 412. For a draft you own that has never been published, the editor updates the draft itself rather than writing a separate row.

An editor on a news site is rewriting a published 1,800-word explainer, closes the laptop at 4:12 pm, and reopens it at 4:40. WordPress shows a notice that a newer autosave exists and offers to restore it. The autosave row is dated 4:11:38, so 22 seconds of typing are gone, but the rest of the rewrite returns.

The published post on the front end stayed at its 9:05 am version the whole time, because an autosave never changes the post_content of the public row.

An autosave is a rolling single copy that gets overwritten, while a revision is a permanent snapshot created when you click Update. Autosave exists to survive a crash, revision exists so you can compare and roll back. Neither is a backup: both live in the same database as the post.

Believing autosave published the change. Shortening AUTOSAVE_INTERVAL to 10 seconds on a shared host and hammering admin-ajax.php or the REST route. Ignoring the restore notice and discarding a better version. Confusing a stuck Saving draft message with a successful save when the request actually failed behind a security plugin. Disabling it in code on a multi-author site and losing work.

If editors complain about lost work, check the browser network tab for a failing autosave request before touching the interval. Keep the default 60 seconds on shared hosting. After a long editing session, click Update yourself; do not rely on autosave as the save.