Control WordPress Autosave Frequency with Heartbeat

WordPress uses the Heartbeat API to keep the editor informed while a post is open. The browser sends periodic requests to admin-ajax.php, and WordPress uses the responses to refresh post locks, report autosave state, and deliver plugin data. Its default heartbeat cycle is about 15 seconds, while an editor may save a draft snapshot on a separate schedule, usually around 60 seconds.

Those timers are related, but they are not interchangeable. Changing the Heartbeat interval alone does not guarantee that Gutenberg or the Classic Editor will create drafts at the same rate. The reliable approach is to set the heartbeat interval where it belongs, then align each editor’s actual autosave timer. This matters for Australian teams supporting sites from Sydney, Melbourne, and Brisbane while some staff work through VPNs, corporate proxies, or mobile hotspots.

How heartbeat interacts with autosave

A heartbeat request is short, authenticated HTTP traffic, not a permanent connection. Core usually includes data for refreshing a post lock and checking autosave information. Plugins can attach their own keys to the same request. On the browser side, JavaScript receives heartbeat-send, heartbeat-tick, heartbeat-error, and connection-lost events, making the API useful for scheduling, diagnostics, and plugin coordination.

The server responds with the current lock holder, lock expiry information, and any autosave details required by the request. A plugin can listen for heartbeat-send and alter the payload before it goes to WordPress, or listen for heartbeat-tick and react when a response arrives. These events describe editor activity around autosaving; they do not expose a universal “save every N seconds” setting.

The distinction is essential. The Classic Editor has an autosave connection with its own cadence, while Gutenberg creates draft revisions through the editor’s REST autosave path. Heartbeat remains important in both because it protects concurrent editing and notifies the browser of autosave-related state. Use the API to control polling and lock refresh, and use the editor-specific setting when the requirement is an exact snapshot frequency.

Configure a scoped heartbeat interval

Add the change in a small site-specific plugin or a child theme rather than editing core. The wp_heartbeat_settings filter exposes the interval sent to the browser. The following example raises it to 30 seconds only on post-editing screens, leaving the dashboard and other administration tools at their normal rate.

add_filter( 'wp_heartbeat_settings', 'acme_post_heartbeat_settings', 20, 2 );

function acme_post_heartbeat_settings( $settings, $screen_id ) {
    if ( ! is_admin() ) {
        return $settings;
    }

    $screen  = function_exists( 'get_current_screen' ) ? get_current_screen() : null;
    $is_post = ( $screen && 'post' === $screen->base )
        || in_array( $screen_id, array( 'post', 'post-new' ), true );

    if ( $is_post ) {
        $settings['interval'] = 30;
    }

    return $settings;
}

A 30-second interval halves the heartbeat requests compared with the 15-second default. A 60-second value is a practical choice for sites with stable hosting and fewer active editors, but it should remain comfortably below the post-lock expiry window, which is roughly 150 seconds by default. Avoid setting the interval to zero, disabling autostart, or relying on values that WordPress normalises below its normal minimum.

Frequency is a performance decision, not a security decision. Heartbeat requests should contain post identifiers, lock information, and nonces rather than complete draft content. That keeps routine background traffic narrow, especially when editorial drafts contain customer information governed by the Privacy Act 1988 and the Australian Privacy Principles. Changing the cadence must not weaken nonce, capability, session, or transport-security checks.

Match the actual editor autosave timer

In Gutenberg, the draft snapshot interval is supplied through block editor settings. Applying block_editor_settings_all lets an administrator change autosaveInterval without modifying JavaScript bundles. The heartbeat can continue checking every 30 seconds while Gutenberg creates a revision every 120 seconds. This separates frequent lock protection from less frequent draft creation.

add_filter( 'block_editor_settings_all', function ( $settings ) {
    $settings['autosaveInterval'] = 120;
    return $settings;
} );

The Classic Editor follows a different path. Classic Editor builds commonly expose their autosave interval through wp.autosave.interval. The following plugin code assigns it after the core autosave script loads and before the Classic Editor begins normal initialisation on standard WordPress installations.

add_action( 'admin_enqueue_scripts', function ( $hook_suffix ) {
    if ( ! in_array( $hook_suffix, array( 'post.php', 'post-new.php' ), true ) ) {
        return;
    }

    wp_enqueue_script( 'autosave' );

    wp_add_inline_script(
        'autosave',
        "if ( window.wp && window.wp.autosave ) { window.wp.autosave.interval = 120; }",
        'after'
    );
} );

The practical choices fit together like this:

Control	What it changes	Sensible starting point	Main caution
wp_heartbeat_settings	Heartbeat polling and lock refresh	30–60 seconds	Do not let requests become too sparse
wp.autosave.interval	Classic Editor draft snapshots	60–120 seconds	Classic Editor only; verify version behaviour
autosaveInterval	Gutenberg draft snapshots	60–120 seconds	Does not control heartbeat traffic
Manual save or explicit revision	A deliberate checkpoint	On demand	Requires a clear publishing workflow

For most editorial teams, a 30-second heartbeat and 120-second autosave interval is a sensible balance: locks are refreshed twice between snapshots, editors lose less work than with a long interval, and the server handles fewer background requests. Teams handling regulated records should also define who can force a manual save or publish a revision. Confirm the final interval in browser developer tools because caching, optimisation plugins, and custom editor scripts can change observable behaviour.

Measure impact on busy Australian sites

Heartbeat load multiplies across every logged-in editor and every plugin that attaches data to the request. At 15 seconds, one idle editor can generate roughly 240 heartbeat requests per hour. Five editors can therefore create about 1,200 requests an hour before plugins add their own work. Moving to 30 seconds halves the core traffic, which can be valuable on Australian hosts with metered or capacity-limited plans.

The local WooCommerce market makes this worth measuring. Australian retailers often combine editorial content, product imports, membership plugins, and payment extensions in one WordPress installation. Some plugins use heartbeat for inventory refreshes or long-running jobs, so lowering the editor interval can affect more than drafts. Record heartbeat timings before and after the change, and inspect slow requests separately instead of assuming every delay comes from autosave.

Autosave is also an editorial safeguard, not a publishing step. For stores quoting prices in Australian dollars, a saved draft may contain a temporary promotion that must not become public without approval. The Australian Consumer Law’s rules against misleading price representations reinforce the need for a clear distinction between a private revision and a published product page. Faster background saves should support review, never replace it.

Test, monitor, and protect the workflow

Test on staging first, then use a controlled administrator account on production. In the browser Network panel, filter for admin-ajax.php and for REST requests to autosave endpoints. Record what happens while the editor is idle, during continuous typing, after a manual save, and after the network drops. Repeat with two accounts editing the same post to confirm that the longer heartbeat interval still refreshes locks without one editor overwriting the other.

Mobile use needs particular attention. Field technicians moving between metropolitan Melbourne and regional Victoria may change from fibre or fixed-wireless connections to mobile data, and a heartbeat request can be delayed when a device changes network or loses signal. If a companion Android application needs an always-on channel for immediate updates, compare that architecture with real-time WebSocket communication. WordPress should still retain ordinary HTTPS polling as the fallback when a persistent socket is unavailable.

Finally, audit custom callbacks and custom admin-ajax handlers as carefully as the intervals. Check that every autosave-related request is nonce-protected, verifies the relevant edit capability, and stores revisions through WordPress APIs. Monitor repeated 403, 429, and 500 responses, and keep the previous values documented so a plugin update or cache purge can be reversed safely. A measured heartbeat interval paired with the editor’s true autosave setting provides predictable drafts without turning every open editing tab into a noisy background service.