Disabling Heartbeat API: When It Actually Helps

The WordPress Heartbeat API is one of those features that runs constantly in the background, costs you real server resources, and that almost nobody thinks about until their host emails them about CPU usage. It is the engine behind autosave, the "Joe is editing this post" lock, and the live updates in your dashboard. It is also one of the most common reasons a quiet WordPress admin area generates a surprising number of POST requests to admin-ajax.php. Disabling or throttling it can meaningfully cut load — but only on the right sites, and doing it bluntly will break editor features your team relies on.

What the Heartbeat API actually does

Introduced in WordPress 3.6, the Heartbeat API is a JavaScript ticker that fires an AJAX request from the browser to wp-admin/admin-ajax.php on a fixed interval. The server responds, optionally with data, and the cycle repeats for as long as the tab is open. It is not a cron job and it is not server-initiated — it only runs while someone has a WordPress page open in their browser.

By default the interval depends on context:

• Post editor (Gutenberg or Classic): roughly every 15 seconds, because this is where autosave and post-locking live.
• Dashboard and other admin screens: every 60 seconds.
• Front end: Heartbeat does not run on the front end by default — it is an admin and editor feature.

What rides on that ticker is genuinely useful. Autosave means a browser crash mid-draft does not cost you 800 words. Post locking is why a second editor opening the same post sees "This content is currently locked" instead of silently overwriting a colleague. WooCommerce uses Heartbeat to poll for new orders on the Edit Order screen and to keep the lock on an order being processed. Some membership and form plugins lean on it too. This matters because the cost of disabling it is not abstract — you are switching those features off.

Why it shows up as a performance problem

The trouble is that every Heartbeat tick is a full PHP request. admin-ajax.php bootstraps WordPress, loads every active plugin, and runs the heartbeat hooks before returning. On a lightly loaded site that is cheap. The problem appears in three specific situations.

Editors who leave tabs open. A content team that keeps five post-edit tabs open all day is generating a request every 15 seconds per tab — roughly 240 requests per hour, per open editor. Multiply across a newsroom and admin-ajax becomes your single busiest endpoint.

Cheap shared hosting. On entry-level shared plans the host caps concurrent PHP workers aggressively — sometimes to two or four. Heartbeat requests are uncacheable POSTs, so they tie up a PHP worker every single time. If those workers are saturated by background ticks, real page loads queue behind them and your TTFB climbs. This is the classic "why is wp-admin so slow" symptom.

Heavy plugin stacks. Because each tick boots the full plugin set, a site running WooCommerce plus a page builder plus a CRM plugin can spend 200–400ms of PHP time per Heartbeat response. At a 15-second interval that is a steady, pointless tax.

Throttle first, disable as a last resort

Here is the practical rule: throttling the interval gives you most of the resource savings while keeping autosave and locking alive. Fully disabling Heartbeat in the editor is rarely the right call because it kills the two features that protect your content. The order of preference, from safest to most aggressive:

1. Slow the interval down from 15s to 60s in the editor. This cuts editor Heartbeat traffic by 75% and is invisible to users — autosave still fires, just a little less often.
2. Disable Heartbeat on the dashboard only, where nothing important depends on it, while leaving the editor alone.
3. Disable it entirely only on single-author sites or staging environments where post locking and live order polling simply do not matter.

The plugin route

For most people the cleanest tool is Heartbeat Control by WP Umbrella (formerly by WP Rocket), a free plugin that gives you three separate switches — one each for the dashboard, the post editor, and the front end — plus a frequency slider from 15 to 300 seconds. The sane configuration for a busy team is: "Allow Heartbeat" on the post editor set to 60 seconds, disable it on the dashboard, and disable it on the front end.

If you run WP Rocket, you already have this. Under WP Rocket → Heartbeat there is a "Control Heartbeat" toggle with three "Reduce activity" / "Disable" options for the same three contexts. "Reduce activity" sets the interval to 120 seconds, which is a reasonable default for most sites. Perfmatters offers an equivalent control under its tools tab.

The code route

If you would rather not add a plugin, you can do it in a small custom plugin or your theme's functions.php. To completely stop Heartbeat everywhere except the post editor — a common compromise — deregister the script conditionally:

add_action('init', function () {
    global $pagenow;
    if ($pagenow !== 'post.php' && $pagenow !== 'post-new.php') {
        wp_deregister_script('heartbeat');
    }
}, 1);

To instead slow it down without disabling it, filter the interval — this is the gentler, recommended approach:

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

Note the interval is clamped server-side to between 15 and 120 seconds, so values outside that range are silently coerced. If you need slower than 120s you must use the JavaScript API or a plugin that does it for you.

When you should NOT disable it

Be deliberate here, because this is where people break things in ways that are hard to diagnose weeks later:

• Multi-author or editorial sites. Killing Heartbeat removes post locking. Two writers can then open the same article and the last to save wins — silently clobbering the other's work. This is the single most damaging side effect.
• WooCommerce stores. The Edit Order screen polls via Heartbeat for new orders and concurrent-edit locks. Disabling it on those screens means staff can step on each other's order edits and miss live updates.
• Sites where autosave matters. Long-form writers who do not religiously hit "Save Draft" will lose work on a crash if autosave is off. Throttling to 60s keeps the safety net; disabling removes it.

How to confirm it actually helped

Do not take it on faith. Open your browser's developer tools, go to the Network tab, filter by admin-ajax.php, and watch: before the change you will see a POST with action=heartbeat ticking on schedule; after, the cadence should slow or stop on the relevant screens. For server-side proof, check your host's PHP worker or CPU graph (Kinsta, WP Engine, SiteGround, and Cloudways all expose this) over the following day — a content team that previously pinned workers during business hours should show a visibly flatter curve.

The honest bottom line

Heartbeat is not a villain. On a small single-author blog the savings from disabling it are negligible and not worth losing autosave. The feature earns a second look specifically when you are on constrained shared hosting, when a team keeps many editor tabs open, or when admin-ajax.php is demonstrably your busiest endpoint. In nearly every one of those cases, throttling the interval to 60 seconds and disabling Heartbeat on the dashboard and front end is the right move — it reclaims most of the wasted PHP cycles without sacrificing the data-protection features the API was built to provide. Reach for a full disable only on sites where post locking and live polling genuinely do not apply.