How to Change the WordPress Autosave Interval

Changing the WordPress autosave interval lets you control how frequently WordPress automatically preserves in-progress content while an editor is working on a post, page or other supported content type.

By default, WordPress uses an autosave interval of:

60 seconds

You can increase that interval to reduce the frequency of automatic save requests, or decrease it when more frequent recovery points are valuable.

For example:

60 seconds
→ WordPress default

120 seconds
→ autosave approximately every 2 minutes

180 seconds
→ autosave approximately every 3 minutes

300 seconds
→ autosave approximately every 5 minutes

The standard WordPress configuration method is the:

AUTOSAVE_INTERVAL

constant.

A three-minute interval can be configured in wp-config.php with:

define( 'AUTOSAVE_INTERVAL', 180 );

Changing the interval is straightforward.

Choosing an appropriate interval requires more thought because autosave is a recovery mechanism, not simply another background request to eliminate.

A longer interval means:

fewer autosave opportunities
+
fewer autosave requests
+
larger recovery gap

A shorter interval means:

more autosave opportunities
+
more autosave requests
+
smaller recovery gap

This guide explains how to change the WordPress autosave interval manually, how the AUTOSAVE_INTERVAL constant works, where to place it, how the Block Editor and Classic Editor use autosave timing, how autosave differs from post revisions and Heartbeat, how to choose an appropriate value and how TheOneWP Autosave Interval provides the same type of control from WordPress settings.

What is the WordPress autosave interval?

The autosave interval defines how frequently WordPress checks whether an editor has unsaved changes that should be automatically preserved.

The default value is:

60 seconds

The official WordPress wp-config.php documentation documents this default and shows how it can be changed.

The relevant constant is:

AUTOSAVE_INTERVAL

The default WordPress configuration

WordPress Core defines the constant only when another value has not already been configured.

Conceptually, Core behaves like:

if (
    ! defined(
        'AUTOSAVE_INTERVAL'
    )
) {
    define(
        'AUTOSAVE_INTERVAL',
        60
    );
}

The actual Core implementation uses:

MINUTE_IN_SECONDS

which represents:

60 seconds

The official wp_functionality_constants() documentation exposes this default directly.

How to change the WordPress autosave interval manually

The normal configuration belongs in:

wp-config.php

Open the file in the root of the WordPress installation.

Look for the section before WordPress finishes loading its configuration.

Add:

define(
    'AUTOSAVE_INTERVAL',
    180
);

This changes the interval to:

180 seconds
=
3 minutes

One-line version

The same configuration can be written as:

define( 'AUTOSAVE_INTERVAL', 180 );

The multiline version is not technically different. It is simply easier to read when configuration files contain several custom constants.

Where should AUTOSAVE_INTERVAL go in wp-config.php?

Place the constant with the other WordPress configuration constants before WordPress loads:

wp-settings.php

A typical section might look like:

define( 'WP_DEBUG', false );

define(
    'AUTOSAVE_INTERVAL',
    180
);

/* That's all, stop editing! */

require_once ABSPATH
    . 'wp-settings.php';

The important rule is:

AUTOSAVE_INTERVAL
must be defined before
WordPress establishes
its default value

Do not define it after WordPress has fully loaded

This is not a useful approach:

add_action(
    'init',
    function () {
        define(
            'AUTOSAVE_INTERVAL',
            180
        );
    }
);

By the time init runs, WordPress Core has already established functionality-related constants.

Configuration constants should be defined early enough to influence the bootstrap process.

Plugins can define the constant early enough

WordPress loads normal plugins before calling the Core function that supplies the default functionality constants.

This means a properly designed plugin can set:

AUTOSAVE_INTERVAL

during its bootstrap process, provided the constant has not already been defined.

This is how a settings-based module can expose the configuration without requiring manual edits to wp-config.php.

Always check whether the constant already exists

Plugin code should not blindly do this:

define(
    'AUTOSAVE_INTERVAL',
    180
);

if another configuration source may already have defined it.

A safer implementation is:

if (
    ! defined(
        'AUTOSAVE_INTERVAL'
    )
) {
    define(
        'AUTOSAVE_INTERVAL',
        180
    );
}

This allows a manually configured:

wp-config.php

value to remain authoritative.

wp-config.php normally has priority

If you define:

define(
    'AUTOSAVE_INTERVAL',
    120
);

in wp-config.php, a later plugin cannot safely redefine the same PHP constant as:

300

A well-designed plugin should detect the existing constant and leave it alone.

TheOneWP respects an existing AUTOSAVE_INTERVAL value

TheOneWP Autosave Interval checks whether:

AUTOSAVE_INTERVAL

has already been defined before attempting to provide its configured value.

This means a manual value in:

wp-config.php

continues to take precedence.

TheOneWP does not disable autosave

The module controls:

how often autosave runs

not:

whether autosave exists

This is an important distinction because completely disabling autosave removes an editing-recovery mechanism rather than merely changing its frequency.

How to change the autosave interval with TheOneWP

With the module enabled, the workflow is:

Enable Autosave Interval
↓
enter interval in seconds
↓
save settings
↓
reload editor
↓
new interval applies

For example:

180

means:

180 seconds
=
3 minutes

Leave the TheOneWP field empty to keep the WordPress default

If no custom interval is configured, the module leaves WordPress to use its normal:

60-second

default.

This provides a straightforward fallback:

custom value entered
→ custom interval

field empty
→ WordPress default

TheOneWP accepts whole seconds

The current module normalizes the submitted interval as a positive integer.

A configured value therefore represents:

number of seconds
between autosave checks

For example:

30
→ 30 seconds

60
→ 1 minute

90
→ 1 minute 30 seconds

180
→ 3 minutes

300
→ 5 minutes

Do not enter milliseconds

The value is measured in:

seconds

not:

milliseconds

So this:

180

means three minutes.

This:

180000

would represent an extremely long interval measured in seconds, not three minutes.

What interval should you use?

There is no universal best autosave interval for every WordPress site.

The right value depends on:

• how long editors work on content;
• how expensive losing recent edits would be;
• how many editors work simultaneously;
• server capacity;
• editing plugins;
• network reliability;
• the complexity of the editor;
• whether autosave activity has actually been measured as a performance problem.

WordPress default: 60 seconds

The default is:

60 seconds

This provides relatively frequent server-side recovery opportunities.

For many normal WordPress websites, there is no compelling reason to change it.

30 seconds: more aggressive recovery

An interval such as:

30 seconds

can provide more frequent autosave opportunities.

This may be useful for:

• long-form editorial work;
• unstable connections;
• high-value writing sessions;
• workflows where losing even one minute of work is frustrating.

The tradeoff is more frequent autosave activity.

120 seconds: moderate reduction

An interval of:

120 seconds

halves the nominal autosave frequency compared with the 60-second default.

It can be a reasonable test value when administrators want fewer editor-side requests without creating a very large recovery gap.

180 seconds: common balanced example

An interval of:

180 seconds

means approximately:

one autosave opportunity
every 3 minutes

This is also the example used in WordPress’s own configuration documentation.

That does not mean WordPress officially recommends three minutes for every site.

It is an example configuration.

300 seconds: lower request frequency

An interval of:

300 seconds

means:

5 minutes

between autosave opportunities.

This may reduce editor-side request frequency noticeably when many users keep editing sessions open.

It also means several minutes of recent work may not yet have reached the server if an editing session fails at an unfortunate moment.

600 seconds and beyond require more caution

Ten minutes can be a substantial gap during active writing.

For example:

editor writes continuously
for 9 minutes
↓
browser crashes
↓
server-side autosave may
not contain those 9 minutes

Other browser-side recovery systems may still help in some editor contexts, but server-side autosave should not be weakened under the assumption that another recovery layer will always rescue the content.

A practical interval comparison

30 seconds
→ very frequent protection
→ more autosave activity

60 seconds
→ WordPress default

120 seconds
→ moderate reduction

180 seconds
→ 3-minute recovery cadence

300 seconds
→ substantially fewer autosave opportunities

600+ seconds
→ larger recovery window
→ use deliberately

These are examples, not official performance tiers

WordPress does not define:

60 = good
180 = better
300 = optimized

Those would be arbitrary labels.

The interval should reflect the actual editing workflow.

What does an autosave actually do?

WordPress periodically evaluates whether the current edited content differs from the stored state.

When an autosave is required, WordPress creates or updates a special revision associated with:

• the post;
• the current editor.

The official wp_create_post_autosave() documentation shows this behavior directly.

WordPress stores one autosave per author per post

If an autosave already exists for:

Post 100
+
User 12

WordPress updates that autosave instead of endlessly creating new autosave records.

Conceptually:

Autosave 1
↓
Autosave 2
replaces it
↓
Autosave 3
replaces it

rather than:

Autosave 1
Autosave 2
Autosave 3
Autosave 4
Autosave 5
...
forever

This distinction is covered in more detail in WordPress Autosave vs. Post Revisions, Explained.

Multiple editors can have separate autosaves

The retention rule is:

one autosave
per user
per post

not:

one autosave
for the entire post

If several users can edit the same content, each may have an autosaved editing state associated with that post.

Changing the interval does not change autosave retention

Whether the interval is:

30 seconds
60 seconds
180 seconds
300 seconds

WordPress does not begin retaining hundreds of autosaves for one editor simply because autosave runs frequently.

AUTOSAVE_INTERVAL does not control post revision retention

This is probably the most important configuration distinction.

AUTOSAVE_INTERVAL
→ editing recovery frequency

WP_POST_REVISIONS
→ historical revision retention

If the objective is:

keep only 10 old versions
of each post

changing:

AUTOSAVE_INTERVAL

is the wrong setting.

See How WordPress Post Revisions Work and What Are WordPress Post Revisions, Really? for revision retention.

Post Revisions is a separate TheOneWP module

TheOneWP Post Revisions controls how many historical revisions WordPress retains.

The responsibilities are:

Autosave Interval
→ recovery timing

Post Revisions
→ history retention

Changing one should not be used as a substitute for configuring the other.

AUTOSAVE_INTERVAL does not control Heartbeat frequency

The WordPress Heartbeat API periodically communicates between the browser and the server while certain administration pages remain open.

It is used for functionality including:

• post locking;
• session-related checks;
• editor coordination;
• plugin-defined Heartbeat communication.

Heartbeat has its own timing behavior.

See The WordPress Heartbeat API, Explained.

Heartbeat interval and autosave interval are different

Think of them as:

Heartbeat
→ browser/server polling cadence

Autosave Interval
→ how frequently WordPress
checks for content that
should be autosaved

Changing:

AUTOSAVE_INTERVAL

does not mean:

all Heartbeat requests
now occur every 180 seconds

Do not disable Heartbeat just to control autosave

This can interfere with unrelated editor functionality.

For example:

• post locking;
• concurrent editing coordination;
• plugins depending on Heartbeat;
• session-related behavior.

Configure the system that corresponds to the problem you are trying to solve.

Autosave and post locking are different

Post locking answers:

Who is editing
this post right now?

Autosave answers:

What recent unsaved
content can be recovered?

See WordPress Post Locking Explained.

Does AUTOSAVE_INTERVAL work in the Block Editor?

WordPress passes an:

autosaveInterval

setting into the Block Editor configuration.

The WordPress editor package includes an:

AutosaveMonitor

component that checks for changes according to the editor’s autosave interval and triggers autosave when necessary.

The official WordPress editor package documentation describes this behavior.

The Block Editor uses WordPress’s REST architecture for autosaves

Modern WordPress exposes autosaves through REST endpoints such as:

/wp/v2/posts/{id}/autosaves

and corresponding routes for supported content types.

The official WordPress REST API revision documentation documents the autosave endpoints.

The transport mechanism can differ from older editor workflows

You may see WordPress documentation historically describe autosaving through:

AJAX

while the modern Block Editor also uses WordPress REST APIs for content operations.

The important configuration concept remains:

AUTOSAVE_INTERVAL
→ WordPress autosave cadence

Do not identify autosave only by looking for one particular:

admin-ajax.php

request.

Classic Editor support

The same Core autosave interval also applies to the traditional WordPress editing workflow.

The Classic Editor historically uses the WordPress administration autosave system and Heartbeat-related processing to persist autosaved content.

The official wp_autosave() documentation describes WordPress’s AJAX autosave logic.

TheOneWP applies the configured interval to both editors

The current Autosave Interval module uses the Core constant rather than implementing a separate editor-specific timer.

Its configured value therefore applies to WordPress’s supported Block Editor and Classic Editor autosave configuration.

Page builders may implement their own save systems

Do not assume every WordPress editing interface relies exclusively on Core autosave.

Page builders can introduce:

• their own autosave system;
• local editor history;
• custom REST requests;
• custom database records;
• cloud recovery systems.

Changing:

AUTOSAVE_INTERVAL

does not guarantee that a third-party builder’s own independent save timer changes too.

Test Elementor, Bricks and other builders separately

If a site depends heavily on a page builder, verify:

• whether the builder uses WordPress Core autosave;
• whether it has its own save frequency;
• whether it maintains separate revision history;
• whether changing AUTOSAVE_INTERVAL changes the actual network activity.

Do not assume a Core constant controls every JavaScript editor installed on WordPress.

Custom post types can support autosave and revisions differently

A custom post type can register support for:

revisions

alongside normal editor features.

Custom editing applications can also implement their own save architecture.

Test the specific content type you care about rather than assuming a standard Post proves every backend workflow.

Why increase the WordPress autosave interval?

Possible reasons include:

• many simultaneous editors;
• limited PHP worker capacity;
• measured autosave-related request volume;
• complex editors producing expensive save operations;
• constrained hosting environments;
• a workflow where a slightly longer recovery window is acceptable.

More editors multiply autosave activity

Consider:

1 editor
×
1 autosave per minute
≈
60 autosave opportunities
per hour

Now consider:

40 editors
×
1 autosave per minute
≈
2,400 autosave opportunities
per hour

Actual requests depend on whether content has changed and on the editor implementation, but concurrency changes the scale substantially.

A longer interval can reduce request frequency

For example:

40 editors
with 60-second interval

versus

40 editors
with 300-second interval

represent very different potential autosave cadences.

This can matter on:

• publishing platforms;
• membership sites with frontend editing;
• large editorial teams;
• shared hosting;
• highly customized wp-admin installations.

Measure before changing the setting

Do not assume autosave is responsible for a slow WordPress admin area.

Admin load can also come from:

• slow database queries;
• plugins;
• REST requests;
• Heartbeat callbacks;
• AJAX polling;
• external HTTP requests;
• WP-Cron;
• large admin tables;
• page-builder processing;
• insufficient PHP workers.

See Reducing WordPress Admin Server Load.

Do not increase the interval solely because admin-ajax.php appears frequently

Many WordPress features use:

admin-ajax.php

Seeing the endpoint in developer tools does not prove autosave is responsible.

Inspect:

• request payload;
• request action;
• response;
• timing;
• initiator;
• editor context.

Use browser developer tools

Open the editor and inspect:

Developer Tools
→ Network

while making content changes.

Observe requests over several minutes.

Then compare:

default interval
versus
custom interval

instead of changing configuration based on assumptions.

Autosave requests do not necessarily equal heavy database writes

An autosave request can result in database work, but WordPress also checks whether the autosaved content is meaningfully different.

Current Core logic can remove an existing autosave when the new autosave content matches the main post.

Therefore:

autosave check
≠
permanent new revision
every time

Do not change autosave simply to solve revision database growth

Normal revisions can accumulate over the lifetime of a post.

Autosaves normally do not accumulate in the same way.

If your database contains large numbers of historical revision records, investigate:

revision retention

before blaming:

AUTOSAVE_INTERVAL

See WordPress Database Bloat, Explained.

Use Post Revisions to control retained history

If you want to limit:

how many old versions
WordPress keeps

use revision-retention configuration instead.

TheOneWP Post Revisions addresses that separate problem.

Does changing autosave reduce database writes?

Increasing the interval can reduce how frequently autosave activity is initiated during active editing.

That can reduce some editor-related requests and writes.

It does not reduce unrelated writes from:

• orders;
• user activity;
• plugin logs;
• WP-Cron;
• metadata;
• options;
• analytics;
• custom tables.

For the broader topic, see How to Reduce Database Writes in WordPress.

Do not use a huge interval as a performance hack

Suppose you set:

define(
    'AUTOSAVE_INTERVAL',
    86400
);

That represents:

24 hours

It technically spaces autosave opportunities far apart, but it effectively destroys much of the usefulness of server-side autosave during normal editing sessions.

That is not a balanced performance optimization.

Do not use an extremely small interval blindly either

This:

define(
    'AUTOSAVE_INTERVAL',
    1
);

asks WordPress to use a one-second interval.

That may create unnecessary request pressure, particularly with many simultaneous editors.

The fact that a value is technically accepted does not make it operationally sensible.

TheOneWP accepts values from one second upward

The current module validates the setting as a positive integer.

That provides flexibility, but administrators should still choose a value appropriate for real-world use.

A configuration interface cannot rescue a deliberately absurd number from being absurd. Software has limits; human creativity unfortunately does not.

What happens if you remove AUTOSAVE_INTERVAL?

If the custom constant disappears and nothing else defines it, WordPress returns to its default:

60 seconds

For example, remove:

define(
    'AUTOSAVE_INTERVAL',
    180
);

from wp-config.php.

On subsequent requests, WordPress will define its normal default value.

What happens if the TheOneWP module is disabled?

The module stops supplying a custom interval.

If no other configuration source defines:

AUTOSAVE_INTERVAL

WordPress uses its normal default.

What happens if TheOneWP is configured but wp-config.php also contains a value?

The manually defined constant remains in control.

For example:

wp-config.php:

AUTOSAVE_INTERVAL = 120

and:

TheOneWP setting:

300

results in the existing PHP constant remaining authoritative.

TheOneWP deliberately checks for that condition rather than attempting to redefine the constant.

Troubleshooting: the new interval does not seem to work

Start by verifying the actual constant.

During development, you can temporarily inspect:

AUTOSAVE_INTERVAL

from a controlled administrator-only diagnostic.

For example:

error_log(
    'Autosave interval: '
    . AUTOSAVE_INTERVAL
);

Do not leave unnecessary production logging enabled permanently.

Check for another definition

Search the codebase for:

AUTOSAVE_INTERVAL

Possible sources include:

• wp-config.php;
• a must-use plugin;
• a normal plugin;
• hosting-specific bootstrap code;
• a custom configuration loader.

Do not define the constant twice

A configuration should have one effective owner.

A messy setup can contain:

wp-config.php
→ 60

MU plugin
→ 120

normal plugin
→ 300

Only the first valid definition wins.

Document which layer owns the setting.

Reload the editor after changing the value

The editor receives autosave configuration during page initialization.

If you change the setting while an editor tab is already open, that existing tab may still be operating with its earlier configuration.

After changing the interval:

save configuration
↓
reload editor
↓
test again

Clear application caches when appropriate

A PHP constant itself is not a normal page-cache value, but unusual hosting or deployment systems may retain:

• PHP workers;
• opcode state;
• container images;
• generated configuration;
• deployment artifacts.

If the file was definitely updated but behavior does not change, verify that the running environment is actually using the edited configuration.

Check that you edited the correct wp-config.php

This matters on:

• staging systems;
• containerized hosting;
• Bedrock-style structures;
• managed WordPress platforms;
• multi-environment deployments.

Editing a local file that is not mounted into the active production container achieves impressively little.

Check whether a page builder has its own autosave

If WordPress reports:

AUTOSAVE_INTERVAL = 300

but requests still occur every minute, inspect which application is creating them.

The activity may belong to:

• page-builder autosave;
• Heartbeat;
• REST polling;
• plugin synchronization;
• preview generation;
• session checks.

Do not identify request purpose by frequency alone

Two requests occurring every 60 seconds may have completely different causes.

Inspect their:

URL
method
payload
action
response
initiator

Autosave and browser-local storage

Modern editors may also maintain browser-local recovery state.

This is useful, but it should not be confused with WordPress’s server-side autosave.

Browser-local recovery
→ stored in browser context

WordPress autosave
→ stored through WordPress
on the server

Local recovery does not make server autosave unnecessary

Browser-local data can disappear because of:

• browser cleanup;
• private browsing;
• device failure;
• storage restrictions;
• switching computers;
• switching browsers.

Server-side autosave protects against a different set of failure scenarios.

Autosave is not a backup

An autosave protects:

current content editing state

It does not protect:

• plugins;
• themes;
• uploads;
• the entire database;
• server configuration;
• all site settings.

TheOneWP Backup Manager handles a separate recovery layer.

Autosave is not revision retention

An autosave protects:

recent unfinished work

A normal revision preserves:

historical saved content

A backup protects:

site or database state

The three layers should not be treated as interchangeable.

How autosave interacts with save_post hooks

Custom plugin and theme code frequently attaches to:

save_post

or related save hooks.

Developers should decide whether their code needs to run during autosave activity.

Expensive save logic can make autosave expensive

Imagine this custom workflow:

save event
↓
call external API
↓
regenerate PDF
↓
clear site cache
↓
send webhook
↓
write analytics record

If all of that runs unnecessarily during autosave activity, the real problem may not be the 60-second interval.

The problem may be poorly scoped save callbacks.

Use wp_is_post_autosave() when appropriate

WordPress provides:

wp_is_post_autosave()

to identify autosave records.

The official wp_is_post_autosave() documentation covers the function.

A save callback can use:

function project_save_post(
    $post_id
) {

    if (
        wp_is_post_autosave(
            $post_id
        )
    ) {
        return;
    }

    if (
        wp_is_post_revision(
            $post_id
        )
    ) {
        return;
    }

    // Intentional save logic.
}

Do not exclude autosaves automatically from every callback

Some code genuinely needs to participate in autosave or revision workflows.

For example, revision-enabled custom metadata may need to follow the content state.

Use the checks when they match the intended behavior rather than copying them into every save callback reflexively.

Changing the interval can hide poorly written plugin code

If one autosave triggers:

200 expensive queries

changing the interval from:

60 seconds
to
300 seconds

reduces how often the expensive operation happens.

It does not fix the underlying:

200-query autosave

problem.

Profile the callback architecture too.

Use server-load analysis before making aggressive changes

Reducing WordPress Admin Server Load covers:

• Heartbeat;
• AJAX;
• REST API traffic;
• database queries;
• WP-Cron;
• external requests;
• PHP workers;
• object caching.

Autosave should be evaluated within that larger system.

How autosave relates to database optimization

A longer interval can reduce some database-write frequency during active editing.

But database growth may instead come from:

• unlimited normal revisions;
• logs;
• expired transients;
• plugin tables;
• metadata;
• orders;
• analytics data.

Do not change autosave settings based solely on database size.

Inspect the database before aggressive cleanup

TheOneWP Database Manager can help inspect WordPress tables and stored data.

The appropriate workflow is:

measure
↓
identify source
↓
change relevant setting
↓
measure again

Use Database Optimizer for cleanup, not autosave timing

TheOneWP Database Optimizer handles supported categories of accumulated database data.

It solves a different problem from:

Autosave Interval

Do not delete autosaves manually as a normal maintenance strategy

Autosaves are managed through WordPress’s revision architecture.

Randomly deleting revision rows from SQL can interfere with content recovery and revision relationships.

Use WordPress-aware APIs and supported maintenance tools.

Testing the autosave interval safely

After changing the setting, use a dedicated test post.

Do not start by testing on:

the company's homepage
during a live campaign

because apparently civilization benefits from avoidable drama.

Step 1: record the original value

Before changing anything, record whether the site currently uses:

WordPress default
or
custom constant

Step 2: configure a visible test interval

For example:

180 seconds

is easier to distinguish from the 60-second default than changing it to 70 seconds.

Step 3: reload the editor

Close or reload the editing screen so it receives the new configuration.

Step 4: modify test content

Add a recognizable unsaved sentence such as:

Autosave interval test
version A

Step 5: inspect network activity

Use browser developer tools and observe the editor for longer than the configured interval.

Step 6: verify autosave exists

Confirm WordPress created or updated the expected autosaved state.

Step 7: test recovery

Use a controlled workflow to confirm recoverable content appears when the autosave is newer than the committed post state.

Step 8: test a normal save

Click:

Save draft
or
Update

and verify normal content saving still works independently.

Test the Block Editor and Classic Editor separately when both are used

Some WordPress installations still use both editing systems for different content types.

Test:

Block Editor
+
Classic Editor

instead of verifying only one interface.

Test custom post types

If the site relies on:

• products;
• portfolio items;
• recipes;
• events;
• courses;
• custom editorial records;

verify the actual custom content workflows too.

Test page builders separately

If the builder maintains its own autosave system, changing the Core interval may have limited or no effect on builder-specific requests.

Test multiple simultaneous editors when scalability is the reason for the change

If the objective is server-load reduction, one editor is not representative of:

20
50
or
100 simultaneous editors

Use realistic staging or load-testing conditions where practical.

Test on staging before large production changes

Especially when the site has:

• custom editor plugins;
• complex page builders;
• multiple authors;
• custom revision metadata;
• workflow plugins;
• heavy administrative integrations.

See WordPress Staging Site Best Practices.

Changing AUTOSAVE_INTERVAL on WordPress Multisite

A constant defined in the main WordPress configuration normally applies at the installation level.

In Multisite, that means one:

AUTOSAVE_INTERVAL

configuration can affect editors across the network.

Do not assume every Multisite site needs the same interval

A network can contain:

Site A
→ busy newsroom

Site B
→ static company pages

Site C
→ internal documentation

A single global constant may not represent the ideal editorial workflow for every site.

A constant is inherently global within the request

Because:

AUTOSAVE_INTERVAL

is a PHP constant, it is not naturally a per-user or per-site configuration mechanism once WordPress has bootstrapped.

More granular behavior would require editor-level configuration or custom logic rather than repeatedly redefining the constant.

Do not attempt to redefine the constant per request after it already exists

PHP constants are not mutable variables.

This architecture:

Site A
→ define 60

Site B
→ redefine 300

inside one already-bootstrapped request is not how constants work.

Managed hosting considerations

Some managed WordPress environments control configuration through:

• environment variables;
• deployment files;
• read-only containers;
• Git-managed configuration;
• host-specific dashboards.

Before editing wp-config.php directly, determine whether manual changes persist across deployments.

Do not modify generated wp-config.php files blindly

If the host rebuilds the file during deployment, a manual:

define(
    'AUTOSAVE_INTERVAL',
    180
);

may disappear later.

Use the configuration layer expected by the hosting platform.

Configuration as code

For managed development environments, autosave configuration can be maintained alongside other environment-specific constants.

For example:

Production
→ 180 seconds

Editorial staging
→ 60 seconds

Local development
→ 60 seconds

Only use different values when there is a real reason to test different behavior.

Do not change production without documenting it

Record:

• previous value;
• new value;
• date;
• reason;
• expected effect;
• test results.

Otherwise a future developer may spend an afternoon wondering why the editor saves every five minutes instead of every minute. Humans do love turning one undocumented integer into an archaeological project.

Common mistake: confusing autosave with revisions

Changing:

AUTOSAVE_INTERVAL

does not control:

how many historical
revisions are retained

Use WordPress Autosave vs. Post Revisions, Explained when those concepts are unclear.

Common mistake: expecting fewer autosaves to clean old revisions

Changing future autosave cadence does not delete historical database records.

Common mistake: setting an extremely long interval to improve performance

The larger the interval, the larger the potential gap between server-side recovery points.

Performance improvements need to justify the editorial risk.

Common mistake: setting the interval to one second

A technically valid integer is not necessarily a useful production configuration.

Common mistake: disabling Heartbeat instead

Heartbeat supports systems other than autosave.

Change the autosave configuration directly when autosave frequency is the requirement.

Common mistake: assuming AUTOSAVE_INTERVAL changes every page builder

Third-party editors may use independent persistence systems.

Common mistake: defining the constant on init

Functionality constants are established earlier in WordPress bootstrap.

Common mistake: defining AUTOSAVE_INTERVAL twice

Keep one source of truth.

Common mistake: putting milliseconds into the constant

The value is in seconds.

Common mistake: changing the file but not reloading the editor

An already-open editor may still be using settings received during its original page load.

Common mistake: testing only by watching admin-ajax.php

The Block Editor also uses REST-based autosave architecture.

Inspect the actual request rather than one familiar URL.

Common mistake: assuming every autosave creates another permanent revision

WordPress maintains one autosave per author per post and updates that autosave as editing continues.

Common mistake: blaming autosave for all revision database growth

Normal revisions and autosaves follow different retention rules.

Common mistake: changing autosave before profiling plugin save hooks

An expensive callback may be the true source of editor load.

Common mistake: ignoring recovery requirements

The purpose of autosave is to protect work.

Any optimization should preserve an acceptable recovery window.

Common mistake: confusing browser-local recovery with server autosave

They provide different layers of resilience.

Common mistake: editing the wrong environment

Verify whether the configuration belongs to:

local
staging
production

before testing.

Common mistake: relying only on database size

Database size does not tell you how frequently autosave requests occur or whether they cause a meaningful performance problem.

A practical WordPress autosave configuration workflow

Identify reason for change
↓
measure current editor activity
↓
record existing interval
↓
choose test value
↓
change AUTOSAVE_INTERVAL
↓
reload editor
↓
test autosave recovery
↓
measure server activity
↓
verify page builders
↓
verify multiple editors
↓
keep or revert change

Example configuration: three-minute interval

define(
    'AUTOSAVE_INTERVAL',
    180
);

This can be a useful starting point when testing whether reducing editor-side autosave frequency materially affects a constrained environment.

It should still be validated against actual editorial recovery requirements.

Example configuration: two-minute interval

define(
    'AUTOSAVE_INTERVAL',
    120
);

This provides a smaller change from the WordPress default.

Example configuration: thirty-second interval

define(
    'AUTOSAVE_INTERVAL',
    30
);

This provides more frequent server-side autosave opportunities for workflows where recovery protection is particularly valuable.

Example configuration: five-minute interval

define(
    'AUTOSAVE_INTERVAL',
    300
);

This substantially reduces nominal autosave frequency compared with the WordPress default but creates a larger potential recovery gap.

Should you use 180 seconds?

Three minutes is a reasonable example for testing.

It is not a magic optimization value.

The correct question is:

Does the reduction in
autosave activity justify
the larger recovery window?

Should you leave WordPress at 60 seconds?

In many cases, yes.

If:

• the editor performs well;
• server load is healthy;
• autosave traffic is not problematic;
• content recovery is important;

there may be no meaningful reason to change the default.

Do not optimize settings merely because they are configurable

A setting existing does not mean the default is wrong.

Use configuration to solve a measured requirement.

How TheOneWP fits into the workflow

TheOneWP Autosave Interval provides a WordPress-admin interface for the same Core autosave timing concept.

The current module:

• accepts an interval in seconds;
• supports positive whole-number intervals;
• leaves WordPress at its default when the field is empty;
• applies the Core autosave interval to the Block Editor and Classic Editor;
• does not disable autosave;
• checks whether AUTOSAVE_INTERVAL is already defined;
• respects a value configured earlier in wp-config.php or another bootstrap source;
• requires the normal TheOneWP administrative settings permissions to change the value.

Use Post Revisions for history retention

Post Revisions manages a different layer:

how much historical
content WordPress retains

Use Database Optimizer for accumulated cleanup

Database Optimizer addresses supported cleanup categories after unnecessary historical data has already accumulated.

Use Database Manager for inspection

Database Manager helps inspect the underlying tables when database behavior requires deeper analysis.

Use Backup Manager for broader recovery

Backup Manager protects a much broader scope than autosave or revisions.

The distinction is:

Autosave Interval
→ editor recovery timing

Post Revisions
→ historical content retention

Database Optimizer
→ database cleanup

Database Manager
→ inspection

Backup Manager
→ broader recovery

WordPress autosave interval checklist

• Remember that the WordPress default is 60 seconds.
• Use AUTOSAVE_INTERVAL to change the Core interval.
• Enter the value in seconds.
• Define the constant before WordPress finishes bootstrapping.
• Place manual configuration in wp-config.php.
• Do not define the same constant multiple times.
• Check whether an MU plugin or normal plugin already defines it.
• Reload the editor after changing the setting.
• Test the Block Editor.
• Test the Classic Editor when used.
• Test custom post types.
• Test page builders separately.
• Do not assume every page builder uses Core autosave.
• Measure editor network activity before optimizing.
• Do not identify autosave by URL alone.
• Remember that the Block Editor uses REST-based autosave infrastructure.
• Remember that one autosave is retained per user per post.
• Do not confuse autosave frequency with normal revision retention.
• Do not change AUTOSAVE_INTERVAL to clean revision history.
• Do not disable Heartbeat merely to adjust autosave.
• Understand the recovery cost of increasing the interval.
• Avoid extremely short intervals without a real requirement.
• Avoid extremely long intervals without a real requirement.
• Profile custom save_post callbacks.
• Exclude autosave from expensive custom save logic where appropriate.
• Use wp_is_post_autosave() when code needs to detect autosaves.
• Test recovery after changing the interval.
• Test several simultaneous editors when concurrency is relevant.
• Test significant changes on staging first.
• Document the configured value.
• Document why it was changed.
• Re-measure server activity after deployment.
• Keep revision retention as a separate decision.
• Keep backups as a separate recovery layer.

Related guides

• WordPress Autosave vs. Post Revisions, Explained
• How WordPress Post Revisions Work
• The WordPress Heartbeat API, Explained
• WordPress Post Locking Explained
• How to Reduce Database Writes in WordPress
• Reducing WordPress Admin Server Load

Final recommendation

Changing the WordPress autosave interval is technically simple:

define(
    'AUTOSAVE_INTERVAL',
    180
);

The more important decision is choosing an interval that preserves a sensible balance between editor recovery and server activity.

WordPress uses:

60 seconds

by default.

There is no need to change that value simply because it is configurable.

If autosave activity has been measured as a meaningful source of load, test a moderate increase such as:

120
180
or
300 seconds

and measure the result.

Remember that increasing the interval reduces autosave opportunities while increasing the amount of recent editing work that may not yet have been preserved on the server.

Also keep the surrounding systems separate:

AUTOSAVE_INTERVAL
→ autosave timing

Heartbeat
→ recurring editor communication

Post Revisions
→ historical content retention

Database cleanup
→ removal of accumulated data

Backup
→ broader site recovery

If database growth is the problem, investigate normal revision retention rather than stretching autosave timing indefinitely.

If wp-admin is slow, profile the full administration workload rather than assuming autosave is responsible.

If a page builder produces its own background requests, verify its own save architecture separately.

And if custom plugin code performs expensive work on every autosave, fix the callback instead of merely making the autosave happen less often.

TheOneWP Autosave Interval provides a settings-based way to manage the Core interval, applies the value to supported WordPress editors, falls back to the native 60-second behavior when no custom value is configured and respects an AUTOSAVE_INTERVAL constant that has already been defined elsewhere.

The best configuration is therefore not the largest or smallest number. It is the shortest interval that provides the recovery protection your editorial workflow needs without creating unnecessary request pressure on the environment running it.