Controlling the Heartbeat API

To control WordPress's Heartbeat API: slow its interval with a filter (or a plugin) so it pings less often, or disable it entirely on specific screens that don't need autosave or the editing lock. Heartbeat is what powers autosave, the "someone else is editing this" lock, and post-lock warnings in the block editor. It works by pinging admin-ajax.php every 15 to 60 seconds while an editor tab is open. On a normal site that's harmless. On a site with several editors working at once, or a page builder open in multiple tabs, those pings add up to real CPU load and can trip resource limits.

The fix is almost always to slow the heartbeat down, not kill it outright, since the lock and autosave features are genuinely useful. There's no UI toggle for this in a default WordPress install, so it means adding a small filter or installing a plugin.

Why it matters on shared resources

Every heartbeat request is a small PHP execution and, on WordPress installs, usually a database round trip. One editor idling on a post page isn't a problem. Ten editors idling on ten post pages, each firing every 15 seconds, adds a steady stream of background requests that competes with real visitor traffic for CPU and entry processes. If your site already runs close to its plan's limits, this is worth checking before you blame the theme or plugins for slowness. For the broader performance picture, see My WordPress site is slow.

Heartbeat traffic hits admin-ajax.php, which lives in wp-admin. It doesn't touch your cached front-end pages, so it won't show up in LSCache full-page cache stats, but it's still PHP execution that counts toward your plan's CPU and entry process limits like any other request.

Slow it down with a filter (no plugin)

WordPress core exposes a heartbeat frequency filter. If you're comfortable with a code snippet, add this to your theme's functions.php or a site-specific plugin:

add_filter( 'heartbeat_settings', function( $settings ) {
    $settings['interval'] = 60; // seconds, default is 15
    return $settings;
} );

This raises the interval to 60 seconds everywhere heartbeat runs, which reduces how often those background requests fire. Autosave and the "post is locked" warning still work, they just check in less often.

Test this on a staging copy first if the site is business-critical. It's a low-risk change, but any code you add to functions.php deserves a quick check that the site still loads cleanly. See Using WordPress staging for the safe workflow.

Disable it on specific screens

If you don't need autosave or the editing lock on certain screens, for example a custom admin dashboard page or a front-end page that loads wp-admin scripts, you can disable heartbeat there entirely:

add_action( 'init', function() {
    if ( is_admin() && ! defined( 'DOING_AJAX' ) ) {
        wp_deregister_script( 'heartbeat' );
    }
} );

Be careful with this on the post editor screen itself. Turning heartbeat off there also turns off autosave and collision detection, so two people editing the same post won't get warned before one overwrites the other's work. Only disable it on screens where that risk doesn't apply.

Using a plugin instead

If editing functions.php isn't an option, a heartbeat control plugin gives you the same filters through a settings page: interval per screen type (dashboard, post editor, front end), and a straight on/off toggle for each. Search "heartbeat control" from wp-admin → Plugins → Add New. Functionally it's doing exactly what the code above does, just through a UI, so use whichever fits your comfort level.

One thing to watch with any heartbeat plugin: if it disables heartbeat on the post editor screen, WooCommerce order pages lose their auto-lock notice too. On a store, two staff editing the same order at once is a real scenario, so keep heartbeat active there even if you slow it elsewhere. See Running a WooCommerce store for more on what stores need that a plain blog doesn't.

What good looks like

A reasonable default for most sites: interval raised to 60 seconds, left active on post/page editors and WooCommerce order screens, disabled on any custom admin screens that don't need it. That keeps the collision protection where it matters and cuts the background request volume everywhere else.

If you've slowed or scoped heartbeat and CPU usage during editing sessions is still high, the cause is more likely a heavy plugin running on every admin request. Run through the plugin audit in My WordPress site is slow before assuming heartbeat is the culprit.