WordPress auto-save is supposed to be invisible. You type, it saves, and you never think about it—until you refresh a draft and realise the last four paragraphs are gone.
The default auto-save interval is 60 seconds. That’s a full minute of typing that can vanish if your browser crashes, your session times out, or a plugin interferes with the AJAX request that writes the draft to the database.
Most solo operators don’t realise how often WordPress doesn’t save, or what conditions break the cycle. Here’s what actually happens, and how to adjust it if you’re losing work.
How WordPress auto-save works
WordPress fires an AJAX request to wp-admin/admin-ajax.php every 60 seconds while you’re editing a post or page. That request writes a revision to the wp_posts table with post_status = 'auto-draft'.
If the request succeeds, you’ll see a faint “Draft saved at [time]” notice near the top of the editor. If it fails—because your session expired, your network dropped, or a security plugin blocked the request—you’ll see nothing. WordPress assumes the save worked.
The problem: WordPress doesn’t retry failed auto-saves. If the AJAX call times out or returns a 403, the next save attempt happens 60 seconds later. Anything you typed in between is at risk.
This is especially common on shared hosting, where PHP execution time limits, memory caps, or aggressive WAF rules can silently kill the auto-save request. You’ll only notice when you reload the page or lose focus and see an older version of your draft.
When auto-save fails silently
Four scenarios break auto-save more often than operators expect:
- Multiple tabs editing the same post. WordPress locks posts to a single session, but if you open the same draft in two browser tabs, the second tab’s auto-save requests return 409 conflicts. The editor doesn’t warn you—it just stops saving.
- Session timeout during long edits. Default WordPress sessions expire after 48 hours, but hosting providers often override this to 2–12 hours. If your auth cookie expires mid-edit, auto-save returns 401 and stops. You’ll only notice when you hit Publish and get bounced to the login screen.
- Security plugins blocking AJAX. Wordfence, Sucuri, and iThemes Security all have rules that can block rapid-fire AJAX requests from the same IP. If you’re editing quickly, the plugin may flag auto-save as suspicious and return 403. Check your security log—most operators never look.
- Browser background-tab throttling. Chrome, Safari, and Edge all throttle JavaScript timers in background tabs to save battery. If you’re editing a post in one tab while reading documentation in another, the auto-save interval can stretch to 2–5 minutes instead of 60 seconds.
How to shorten the auto-save interval
WordPress lets you override the 60-second default with a single line in wp-config.php:
define( 'AUTOSAVE_INTERVAL', 30 );
That changes the interval to 30 seconds. You can set it as low as 10 seconds, but be aware: shorter intervals increase database writes and server load. If you’re on shared hosting with tight I/O limits, aggressive auto-save can slow down the editor or trigger rate-limit warnings from your host.
A better approach for most solo operators: leave the interval at 60 seconds, but add client-side protection with a browser extension like Textarea Cache (Chrome) or Lazarus (Firefox). These tools store form content in local browser storage every few seconds, independent of WordPress. If the page crashes or the session expires, you can recover the text from the extension’s cache.
What gets saved and what doesn’t
WordPress auto-save only writes the post title, content, and excerpt. It does not save:
- Custom field values (ACF, Pods, or manual meta fields)
- Featured image selections
- Category or tag assignments
- Gutenberg block settings (only the block HTML is saved, not inspector-panel metadata)
If you’re using a page builder like Elementor or Bricks, auto-save behaviour is entirely different—they maintain their own revision systems and save intervals. Check the plugin’s settings; most default to 60–120 seconds and store data in custom database tables, not wp_posts.
When to disable auto-save
Some operators disable auto-save entirely to reduce database bloat, especially on sites with hundreds of posts and thousands of revisions. You can turn it off with:
define( 'AUTOSAVE_INTERVAL', 86400 );
That sets the interval to 24 hours—effectively disabling it. But unless you’re manually saving every few minutes with Cmd+S or Ctrl+S, this is risky. A single browser crash can lose an hour of work.
A safer middle ground: leave auto-save enabled, but limit the number of revisions WordPress stores. Add this to wp-config.php:
define( 'WP_POST_REVISIONS', 5 );
That keeps only the five most recent revisions per post. It prevents database bloat without removing the safety net.
Reply and let us know: Have you ever lost a draft to a failed auto-save? What interval do you run, and have you adjusted it? Hit reply—we read every response.