WordPress Autosave Not Working: Check REST API, Heartbeat and WAF

This article is a localized edition of the Japanese original. Read the Japanese original

When WordPress autosave stops working, the communication between the editor and the server is almost always failing somewhere. There are many possible causes, but looking at which request failed, and with which status code, in your browser's developer tools narrows them down quickly. This article explains how autosave works and then walks through isolating the cause step by step.

How autosave works

The two editors use different channels for autosave. First check which one you are using.

The interval for autosaving to the server is set by the AUTOSAVE_INTERVAL constant in wp-config.php, and the default is 60 seconds.

Where the autosave goes also differs. For your own draft, the autosave overwrites the post itself. When you edit a published post or another user's draft, the original post is left alone and the autosave is stored as a separate "autosave" revision (for post ID 123, a revision with the slug 123-autosave-v1). So if a published post was "autosaved" but the public page has not changed, that is by design, not a bug.

Setting WP_POST_REVISIONS to false to disable revisions does not stop autosave. Autosave runs independently of the revision settings.

Step 1: Find the failing request in developer tools

1. With the editor open, open your browser's developer tools (F12 in Chrome or Edge) and select the "Network" tab
2. In the filter box, type autosaves for the block editor or admin-ajax for the Classic Editor
3. Change the content a little and wait about 60 seconds (or click "Save draft")
4. Check the status code of the request that appears and the contents of its "Response" tab

The main causes by status code are:

If the response is not JSON starting with { but an HTML error page or a login screen, something in front of WordPress (a WAF, a cache or a redirect) is handling the request. This is the situation in which the block editor reports that the response is not a valid JSON response.

Step 2: Check that the REST API is available

Saving in the block editor depends on the REST API. In the admin, go to "Tools" → "Site Health" and check whether it reports a problem saying the REST API is unavailable.

You can also check from the command line.

# If JSON comes back, the REST API entry point works
curl -s https://example.com/wp-json/ | head -c 200

# A form that does not depend on permalink rewriting
curl -s "https://example.com/?rest_route=/" | head -c 200

If only the second command returns JSON, requests to /wp-json/ are not reaching WordPress. Check the rewrite rules in .htaccess on Apache, or the try_files setting on Nginx. Going to "Settings" → "Permalinks" and clicking "Save Changes" without changing anything regenerates the rewrite rules.

If a plugin or custom code restricts the REST API, check that it does not also block logged-in users. Restricting the REST API is covered in How to fix WordPress REST API errors.

Step 3: Check for blocking by a WAF or security plugin

If the content contains strings that look like code or SQL (<script>, SELECT … FROM, ../ and so on), a hosting provider's WAF or ModSecurity may treat the save as an attack and stop the POST with a 403. If only certain posts fail to save, or saving breaks after you paste certain text, this is a likely cause.

• Check the WAF log in your hosting control panel for a block recorded at the time you saved
• If there is one, exclude the matching rule, or temporarily turn off the WAF while you work and see whether saving succeeds
• If you use a security plugin with a firewall feature, check that plugin's block log as well

Do not leave the WAF turned off; restore the setting once you have found the cause.

Step 4: Check the login session and nonces

During long editing sessions, your login can expire. When WordPress detects this it shows a dialog asking you to log in again, and that detection also relies on Heartbeat requests. The nonce (X-WP-Nonce) that the block editor sends to the REST API is also refreshed through Heartbeat responses.

So if Heartbeat is disabled or its interval is extremely long, a long editing session can end with 401 or 403 responses (with a code such as rest_cookie_invalid_nonce in the response), and saving fails. Check the Heartbeat settings in Step 6.

Causes of frequent logouts are covered in How to fix WordPress sessions that expire too easily, and nonce errors in Investigating frequent "Invalid nonce" errors in WordPress.

Step 5: Log and check PHP errors

If you get a 500, write PHP errors to a log to find the cause. Set the following constants in wp-config.php (this example uses WP-CLI).

# Back up wp-config.php before you start
cp wp-config.php wp-config.php.bak

wp config set WP_DEBUG true --raw
wp config set WP_DEBUG_LOG true --raw
wp config set WP_DEBUG_DISPLAY false --raw

Trigger an autosave in this state and check the errors written to wp-content/debug.log. Once you know where the error comes from (the file path of a plugin or theme), update that plugin or theme, or temporarily deactivate it to confirm. When you are done, set WP_DEBUG back to false.

Step 6: Check for settings that disable Heartbeat or autosave

Settings that disable Heartbeat or lengthen its interval are sometimes added to speed up the site or reduce server load. Some caching and performance plugins have this feature too (for example, WP Rocket's Heartbeat control). Configure them so that Heartbeat keeps running on the post editing screen.

Theme or custom plugin code may also disable it. The following commands search for likely code.

cd /var/www/html

# Deregistered Heartbeat/autosave scripts, or a changed interval
grep -rn --include='*.php' -e "wp_deregister_script( *['\"]heartbeat" -e "wp_deregister_script( *['\"]autosave" -e "heartbeat_settings" wp-content/

# Has wp-config.php changed the autosave interval?
wp config get AUTOSAVE_INTERVAL

If wp config get AUTOSAVE_INTERVAL returns an error saying the constant is not defined, the default of 60 seconds is in use. If a very large value is set, autosave effectively never runs. Unless you need it, delete the definition.

wp config delete AUTOSAVE_INTERVAL

Step 7: Isolate plugin and theme conflicts

If you still have not found the cause, suspect a plugin or theme conflict. Deactivating every plugin on a production site affects visitors too, so use one of the following approaches.

• Test on a staging site: on a copy of production, deactivate all plugins, switch to a default theme and try saving (How to create a WordPress staging environment)
• Troubleshooting mode in the Health Check & Troubleshooting plugin: deactivates plugins and switches to a default theme for your own login session only. What visitors see does not change

On a staging site, isolate the cause with WP-CLI like this.

# Record the current state
wp plugin list --status=active --field=name > active-plugins.txt

# Deactivate everything and check whether autosave works
wp plugin deactivate --all

# Reactivate one at a time to find the plugin that reproduces it (e.g. classic-editor)
wp plugin activate classic-editor

# When you are done, restore the recorded state
wp plugin activate $(cat active-plugins.txt)

# Switch to a default theme (specify an installed theme)
wp theme activate twentytwentyfive

Use a theme name exactly as shown by wp theme list for wp theme activate.

Step 8: Check cache and CDN settings

If a page cache or CDN caches or rewrites requests to /wp-json/ or /wp-admin/, save responses can be stale or fail. In your caching plugin or CDN settings, make sure at least the following are excluded from caching:

• /wp-admin/ (including admin-ajax.php)
• /wp-json/
• Logged-in users (requests carrying the login cookie)

Recover autosaved content

Even when saving has failed, your content may still be there.

• Browser backup: when you reopen the editor in the same browser, a notice may say that the backup of this post in your browser differs from the version shown. You can view and restore it from the notice's button. It lives in sessionStorage, so it disappears when you close the tab or browser
• Server autosave: if the editor shows a notice that there is an autosave of this post more recent than the version below, open the autosave from its link and restore it
• Revisions: in the block editor, you can compare and restore earlier saves from "Revisions" in the settings sidebar

While saving keeps failing, copy what you have written into a text editor or similar so you do not lose your work.

Summary

• The block editor autosaves through the REST API and the Classic Editor through Heartbeat (admin-ajax.php). The interval is AUTOSAVE_INTERVAL (60 seconds by default)
• Start by checking the failing request and its status code in developer tools
• For 403, suspect a WAF, a security plugin or an expired nonce; for 404, the REST API URL; for 500, a PHP error
• Disabling Heartbeat also stops nonce refreshes and login-expiry detection, so saving can fail after long editing sessions
• Isolate conflicts on a staging site or in troubleshooting mode, rather than deactivating all plugins on production at once
• Exclude /wp-json/ and /wp-admin/ from caching

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)