Why WordPress Heartbeat API Spikes CPU and How to Tune It

If CPU rises while several editors work in the dashboard, PHP-FPM workers fill up or admin-ajax.php becomes prominent in access logs, WordPress Heartbeat API high CPU is one possible cause. A CPU graph alone, however, cannot prove that Heartbeat is responsible.

Heartbeat API is a browser-to-WordPress communication mechanism that sends regular, small requests. WordPress can use these requests for sessions, autosaves, post locking and live information supplied by plugins. Each request is still processed by WordPress, so the total PHP and database work can grow when many browsers send requests or a plugin adds expensive processing.

This guide shows how to measure Heartbeat-related load, separate it from other causes and choose the narrowest correction. The goal is not to disable Heartbeat indiscriminately, but to reduce calls that are not needed while preserving editor features that your site depends on.

How Heartbeat can raise CPU usage

Heartbeat runs at regular intervals in the browser. The browser sends a request to WordPress, and WordPress processes it before returning a response. In the dashboard, these requests commonly use /wp-admin/admin-ajax.php.

A Heartbeat request may look small in the browser, but the server does more than read one value. WordPress loads its core, active plugins and theme, runs relevant hooks and may execute database queries. Each operation may be brief, yet the combined PHP execution time becomes significant when many browser tabs make requests at the same time.

The interval can vary by context and by the WordPress version, editor and plugins in use. More frequent calls in the dashboard and less frequent calls on the front end can be normal. The editor may behave differently because it supports autosaving and post locking. For that reason, do not measure only the number of seconds between requests. Find out which code each request activates.

The expensive work is often in a plugin handler

Heartbeat is a transport channel. A plugin can use it for stock checks, live notifications, session checks, analytics or a custom AJAX operation. If its handler runs an expensive query, connects to an external service or processes a large dataset on every call, CPU and database usage can rise.

Load that appears only while an editor is open may involve autosave, post locking or an editor-related plugin. Load that increases with many administrator sessions may come from the combined timers of all active tabs. On WooCommerce sites, dashboard features for orders, stock or notifications can also make Heartbeat requests more expensive.

How to measure Heartbeat-related load

Start by confirming the timing relationship between the CPU increase and Heartbeat requests. If you blame Heartbeat based only on a high graph, you may disable the wrong plugin or disrupt editor features without addressing the cause.

Establish the time window with server metrics

Review CPU usage, PHP-FPM active workers, load average and database activity over the same period. Note whether the increase begins when an editor opens, when a certain number of users sign in or when background jobs run.

Separate PHP-FPM web workers from CLI cron or queue workers. A WP-Cron task or CLI queue does not consume a PHP-FPM web worker when it runs without making an HTTP request. If both processes use CPU during the same period, do not automatically attribute the increase to Heartbeat. A cron task, database operation or backup can be an independent source of load.

Confirm the request in browser network records

Sign in with an administrator account and open the screen where the problem occurs. In the browser developer tools, open the Network tab and filter for admin-ajax.php. Record the request interval, response time and response size. Then close the editor and check whether the requests stop or change.

An action=heartbeat value in the request body is a strong indication that the call belongs to the Heartbeat flow. This does not measure CPU by itself. It tells you which screen is generating requests and how often.

Compare total volume in access logs

Count admin-ajax.php requests in the web-server access logs for the same time window. If available, compare them with dashboard user counts, response status and request duration. Not every request to this URL is a Heartbeat request, so do not interpret the path alone as proof.

If your monitoring system records processing time per request, compare slow Heartbeat calls with the total number of short calls. One slow request and many short requests can create different bottlenecks, and they require different fixes.

Find an expensive application handler

For a temporary investigation, use a development tool such as Query Monitor, a staging environment or server-side profiling data. The objective is to identify the query, hook or plugin that runs during Heartbeat. Check that the tool supports your WordPress and PHP versions, and do not leave a profiling tool enabled permanently on production; test it first in staging where possible.

If you deactivate a plugin to compare load, make a backup first, schedule the test during a lower-traffic period and define the rollback step. Do not randomly disable critical components such as WooCommerce or a security plugin. Compare them in staging or use a controlled production test with a clear recovery plan.

Separate the cause by the observed symptom

The timing and location of the CPU increase help determine the safest correction. If requests appear in both the dashboard and front end, test those contexts separately instead of applying one broad setting.

CPU rises only while an editor is open

Autosave, post locking and editor-related plugins are the first candidates. Open the same post in two browser sessions and compare post-lock behavior, draft saving and admin-ajax.php frequency. If the load occurs only for one content type, inspect the plugin or custom code associated with that type.

In this situation, increasing the interval or fixing the expensive handler is narrower than disabling all Heartbeat traffic. Changing the editor’s autosave interval separately may not fix the issue; first confirm whether both operations use the same request.

CPU rises with many dashboard users

Every open tab can send regular requests. As the number of users and tabs grows, short operations can still fill the PHP-FPM pool. Increasing PHP-FPM limits immediately may only allow more work to wait at once, so measure request frequency and duration first.

For broader capacity planning, the article on WordPress resource planning explains why traffic, concurrent users and workload should be considered together. It does not provide a universal CPU value for Heartbeat, but it can help you assess whether the host has enough capacity for the complete workload.

Heartbeat requests also appear on the front end

Front-end Heartbeat calls may support live notifications, carts or custom theme features. If none of those features is needed, removing Heartbeat only from the front end can be narrower than changing dashboard behavior. Autosave and post locking in the dashboard can remain unaffected.

If a plugin uses Heartbeat on the front end, confirm that the feature is genuinely unnecessary before removing it. Live carts, notifications and session-related features can fail quietly. During testing, use browser developer tools to look for errors and missing responses.

Database wait is rising more than CPU

Many Heartbeat queries can increase database connection time, disk wait and slow-query activity even when the CPU graph is not the main symptom. Increasing the number of PHP-FPM workers alone will not fix a database bottleneck.

Sites without a suitable object cache may repeatedly fetch the same data. The article on Redis/Memcached Object Cache explains the cache options, but verify that caching actually reduces the relevant queries and does not create consistency problems. An object cache does not replace fixing an unnecessary or inefficient Heartbeat handler.

Choose the narrowest correction

Once measurements confirm that Heartbeat contributes to the load, there are three main intervention levels: increase the interval, remove Heartbeat from an unnecessary context or fix the expensive handler. The first is usually easiest to reverse; the third addresses the root cause most directly.

Increase the dashboard interval

If an editor feature does not need to update every few seconds, increasing the dashboard interval can reduce request volume while keeping Heartbeat enabled. Test this in staging or with a limited administrator group first. Prefer a version-controlled custom plugin or mu-plugin over adding code directly to a theme or an update-prone plugin file.

The following example uses the heartbeat_settings filter to change the interval to 60 seconds in the administration context. This filter and the resulting behavior should be checked against the WordPress version, editor and plugins on your site. The value is an example starting point, not a universal recommendation. Test autosave and post locking before using it in production.

<?php
add_filter( 'heartbeat_settings', function ( $settings ) {
    if ( is_admin() ) {
        $settings['interval'] = 60;
    }

    return $settings;
} );

Before applying the code, make sure it can be loaded with valid PHP syntax and that your deployment method supports rollback. Confirm that the current file and site backup are usable if you need to restore the previous state.

After the change, open an editor, save the post as a draft and open the same post in a second session to test locking. Check the browser request interval and compare PHP-FPM activity with the same period before the change. If the result is worse, remove the code and return to the previous state.

Remove Heartbeat from the front end when it is unnecessary

If you have confirmed that no front-end feature depends on Heartbeat, you can consider removing only the front-end script. This example targets front-end asset loading and does not target the dashboard.

<?php
add_action( 'wp_enqueue_scripts', function () {
    wp_deregister_script( 'heartbeat' );
}, 100 );

Before using this code, check whether the theme or plugins depend on front-end Heartbeat. Test live notifications, carts, user sessions and custom AJAX features separately. If a feature breaks, roll back the change and preserve the feature while fixing only the unnecessary handler.

Fix the expensive plugin handler

If profiling shows that a particular plugin runs a costly query during Heartbeat, changing the interval only reduces the symptom. Update the plugin, review its supported settings or ask its developer whether the operation can use another mechanism. For custom code, narrow the query so it runs only for the required user, screen or data change.

A job that connects to an external API on every Heartbeat request is especially fragile. Network delay can keep a PHP-FPM worker busy and increase the queue for concurrent requests. Caching the result, moving the task to a scheduled job or running it only after an explicit user action may be better. These changes affect application behavior, so test them in staging and prepare a rollback.

Verify the result after changing Heartbeat

A successful correction is more than a lower CPU graph. Check request volume, PHP-FPM wait state, database latency and WordPress features together.

• In the browser Network tab, confirm that admin-ajax.php and action=heartbeat calls occur at the expected frequency.
• Compare CPU, active and waiting PHP-FPM workers and response times with the same period before the change.
• Test editor autosave, post locking and editing behavior across two sessions.
• If front-end Heartbeat was removed, test live notifications, carts and session-related features.
• Check access logs for new error responses or unusually long request times.

The WordPress Site Health report can provide additional warnings about configuration, updates and the hosting environment. Use it as a complement to Heartbeat measurements, not as a replacement for request and server data.

When does disabling Heartbeat make sense?

Disabling Heartbeat entirely is reasonable only when the screens and plugins you use do not need this communication. A single-author site that manages mostly static content and has no front-end live features may have a narrower use case. Even then, account for the operational impact of losing dashboard autosave and post locking.

Full deactivation is riskier on multi-author sites and WooCommerce dashboards. Editor conflicts, lost drafts or broken plugin features may cost more than the CPU reduction. Increasing the interval, targeting only the front end or fixing the expensive handler is usually more controlled.

Frequently Asked Questions

Is Heartbeat API the same as WP-Cron?

No. Heartbeat is regular browser-to-WordPress HTTP communication. WP-Cron runs scheduled tasks. A plugin can perform cron-like work during a Heartbeat request, but the two mechanisms are not the same. A CLI queue worker is also a separate process and does not occupy an FPM worker unless it makes an HTTP request.

Can Heartbeat increase RAM usage as well as CPU?

Yes, indirectly. Every PHP request uses memory, and more concurrent requests can increase total memory consumption in the PHP-FPM pool. Monitor memory and active PHP-FPM workers alongside CPU.

Can a caching plugin solve a Heartbeat problem?

Page caching usually does not handle session-dependent admin-ajax.php requests directly. Object caching may reduce repeated database queries, but it does not remove a faulty or unnecessary Heartbeat handler.

Will a 60-second interval delay autosave?

Operations that use Heartbeat may run less often, so a delay is possible. The exact effect depends on the WordPress version, editor and plugins. Test draft saving and post locking on real editor screens before deployment.

Actionable checklist

1. Record when CPU rises, how many users are active and which dashboard screens are open.
2. Confirm admin-ajax.php calls and the action=heartbeat value in browser network records.
3. Compare access logs, PHP-FPM metrics and database latency over the same period.
4. Isolate the plugin or custom code that makes Heartbeat expensive in staging.
5. Test the narrowest change first: increase the dashboard interval or remove only unnecessary front-end calls.
6. Recheck autosave, post locking, live features and error logs after the change.
7. If CPU does not fall, investigate cron, queues, database queries and traffic outside Heartbeat.

Your next step is to collect a short access-log sample and browser network capture from the period when the problem occurs. Together, they show whether Heartbeat is creating the load and which correction is least likely to cause side effects.