Controlling How Often WordPress Autosaves

The advice to raise this value for database health is based on a misunderstanding of what autosaves do. AUTOSAVE_INTERVAL sets how many seconds pass between automatic saves in the editor. An autosave does not create a new row each time — it overwrites the same one, per author, per post. Making it less frequent therefore saves almost no storage, while costing exactly the thing autosave exists to protect.

The setting

define( 'AUTOSAVE_INTERVAL', 120 );

The value is in seconds and the default is 60. It goes in wp-config.php above the stop-editing comment, like every other constant there.

That is the whole feature. There is no per-post-type variant and no way to disable it through this constant alone; a very large number is the closest approximation, and it is a worse idea than it sounds.

What actually accumulates

Three things get confused with each other, and only one of them grows:

A post edited fifty times has up to fifty revisions and one autosave. If a database is heavy with post rows, revisions are the cause, and the setting to reach for is the revision limit rather than this one — the subject of WordPress post revisions.

The heartbeat is the other thing being blamed

The admin makes periodic background requests to handle post locking, to warn when someone else is editing, and to keep the session useful. That is the heartbeat, and it is separate from autosave. It is also the thing people usually mean when they say the editor is generating constant traffic.

On a busy shared host that traffic is a real cost, and it is a genuine contributor to a slow WordPress admin. Slowing it is a different change from this constant, and slowing it too much disables the post-locking warning that stops two editors overwriting each other.

What a long interval costs

The interval is the size of the window in which work can be lost. A browser crash, a closed laptop, a dropped connection or an accidental navigation all lose whatever was written since the last save.

For a site where people write in the editor directly, sixty seconds is already a meaningful amount of typing. Doubling it to save a fraction of a megabyte is a poor trade. For a workflow where text is written elsewhere and pasted in, the window matters less — but then autosave was never costing anything either.

When changing it is reasonable

There are two honest cases:

• A very slow server, where each save request is heavy enough that a save every sixty seconds is noticeably interrupting the editor. Raising the interval is a symptomatic fix while the underlying slowness is addressed, per speeding up a WordPress site.
• Posts with very large content, where the payload of each autosave is big enough to be worth sending less often.

In both cases the right move is a modest increase — 120 or 180 seconds — rather than a number chosen to effectively switch the feature off.

Recovering an autosave

An autosave that is newer than the post shows a notice in the editor offering to restore it. Only the most recent one exists, so there is no history to browse, and once a real save happens the autosave is superseded.

This is worth knowing before raising the interval, because it is the entire recovery story. There is no second copy elsewhere, and a long interval means the copy that exists is older.

Verify the change is live

Open a post, type a few words, and watch for the saving indicator. With the default it appears about a minute after you stop; with a raised value it should take correspondingly longer.

If nothing changes, the constant is below the stop-editing comment in wp-config.php and is being defined after WordPress has read the value — the same trap that catches DISALLOW_FILE_EDIT. If the editor is not saving at all, that is a different failure and the trail starts at the block editor not working.