Skip to content
Website Speed

WordPress Heartbeat API: What It Does and How to Limit It

Heartbeat keeps your browser and server in touch for post locks and login checks. Here is when it adds load and how to limit it without breaking editing.

A laptop showing website analytics charts
7 sections · 7 min read
In this article · 7 sections

Three people on your team keep the WordPress dashboard open all day, and on busy afternoons the site drags for everyone. A forum reply blames the WordPress Heartbeat API and says to switch it off with a plugin. Before you do, it is worth knowing what those background requests are for, because a few of the features they support are ones you would miss.

Below: what Heartbeat does, when it genuinely adds load, how to see it, and how to limit it without breaking editing. The many other reasons a dashboard can be sluggish are in our post on why the WordPress admin is slow when the site is not.

What the WordPress Heartbeat API does

Heartbeat is a small system built into WordPress that lets the browser and the server keep in touch while a page is open. At regular intervals, a script in your browser sends a short request to the server, and the server replies with anything the page should know. Each request is called a tick.

WordPress itself uses it for a few quiet but useful jobs:

  • Post locking. When one person is editing a post, others who open it see a warning that it is in use, and can take over deliberately rather than overwriting each other’s work.
  • Login expiry. If your session runs out while you are working, a login box appears over the page so you can sign back in without losing what you typed.
  • Refreshing security tokens on long editing sessions, so saving does not fail with an expired-link error.
  • Autosave in the classic editor. The block editor handles its own autosaving through the REST API, but still relies on Heartbeat for post locks.

Plugins can use the same channel. Some use it to show live notifications in the dashboard, refresh order or stats widgets, or keep a session alive. That is where most Heartbeat trouble comes from.

Where it runs

Heartbeat runs in the WordPress dashboard and the editor. By default it ticks about every 15 seconds while you are in the post editor and about every 60 seconds on other admin screens, and it slows down further when the browser tab is in the background.

On the public front end, Heartbeat does not load by default. If you see heartbeat requests from ordinary visitors, a plugin or theme has added it there.

Why a small request can add up

Each tick goes to admin-ajax.php, which loads WordPress, all active plugins, and the admin environment, then runs whatever code has asked to respond. It is never served from a page cache. On its own, one tick is a modest amount of work.

The load grows in a few predictable situations:

  • Several people with the dashboard open at once. Each open tab sends its own ticks. A team of editors, each with several tabs, multiplies the requests.
  • Small hosting plans. Shared plans limit how many PHP processes can run at the same time. Heartbeat ticks take up those same slots, so visitors and staff end up waiting behind them. Our explainer on how PHP workers limit a site describes that queue.
  • A plugin doing heavy work on each tick. If a plugin hooks into Heartbeat to run a database report or call an outside service, every tick carries that cost.
  • Heartbeat on the front end. When a plugin loads it for every visitor, the number of ticks scales with your traffic, and none of them is cached.

Heartbeat slowing the site is usually one of these four, not Heartbeat itself.

How to see Heartbeat activity

Three simple checks tell you whether Heartbeat is worth your attention.

  1. In the browser. Open a dashboard screen, then your browser’s developer tools, and go to the Network tab. Type admin-ajax in the filter. Leave it for a couple of minutes. Click any request and look at its Payload or Request tab; Heartbeat ticks include action: heartbeat. Note how often they come and how long each takes. Repeat on the post editor.
  2. On the public site. Do the same on a public page in a private window, logged out. If heartbeat ticks appear for a logged-out visitor, something has loaded it on the front end.
  3. In the server logs or host statistics. Count POST requests to admin-ajax.php over a day. A high count is not proof on its own, because many plugins use the same file; the payload check above tells you which share is Heartbeat. Our guide to tracing admin-ajax requests to the plugin that sends them covers the other callers.

If ticks return quickly and there are only a few per minute per open tab, Heartbeat is probably not your problem. If each tick takes seconds, some plugin is doing real work on every one. On a staging copy, switch plugins off one at a time and watch the tick times in the Network tab until they drop.

Limiting it safely, place by place

The safest approach treats the three places Heartbeat runs differently.

Where What depends on it Sensible approach
Public front end Usually nothing in WordPress itself; sometimes a plugin feature Disable if no plugin feature needs it, then test that feature
Dashboard screens Login expiry notice, plugin notifications and widgets Lengthen the interval rather than switching off
Post editor Post locking, login expiry, token refresh, classic autosave Leave it on; lengthen the interval modestly if needed

Using a plugin

You do not need code for this. Several performance plugins include Heartbeat controls: WP Rocket and Perfmatters have settings for it, LiteSpeed Cache has one among its tools, and there is a standalone plugin called Heartbeat Control. They let you choose, per location, whether to allow, slow or disable Heartbeat. If you already use one of these performance plugins, use its setting rather than adding another plugin.

Using code

If you prefer a snippet in a small custom plugin or a child theme, WordPress offers a filter for the interval. This example asks for a tick about once a minute:

add_filter( 'heartbeat_settings', function ( $s ) { $s['interval'] = 60; return $s; } );

WordPress accepts an interval between 15 and 120 seconds, so a larger number will not stretch it further than that. Make one change at a time and test.

Testing that nothing broke

After changing Heartbeat settings, check the features that depend on it:

  • Open the same post in two different browsers logged in as two users. The second should see that the post is being edited.
  • Leave an editing tab open for a long while, then save. It should save without an expired-link error.
  • Check any plugin features that show live information in the dashboard, such as new order alerts or chat notifications.
  • If you disabled it on the front end, test whatever feature loaded it there, for example a membership area or a live notice.

Then measure the effect you were after: fewer admin-ajax requests in the logs, lower resource graphs at the host, or faster responses for visitors at busy times. If nothing changed, Heartbeat was not the bottleneck, and the time is better spent on the other topics in the section guide on what makes a WordPress site heavy.

Mistakes to avoid

Disabling Heartbeat everywhere. It stops the ticks, and it also removes post locking and the login expiry box. On a site with more than one editor, two people can then overwrite each other’s work without warning.

Treating every admin-ajax request as Heartbeat. Forms, carts, view counters, search and many other features use the same file. Check the action in the payload before deciding.

Ignoring the plugin behind heavy ticks. If ticks are slow because a plugin does expensive work on each one, slowing Heartbeat only spreads the cost out. Fix or replace that plugin.

Leaving dozens of dashboard tabs open. A simple habit change for a busy team, and free. Background tabs tick less often, but they still tick.

For how this fits with page weight, caching and server time, the overview on making a website faster shows where background requests sit among the other causes.

Frequently asked questions

Does Heartbeat affect visitors who are not logged in?

Not by default, because WordPress only loads it in the dashboard and editor. It affects visitors indirectly when staff ticks compete for limited server resources, and directly only if a plugin or theme loads Heartbeat on public pages. Check a public page in a private window to see whether any heartbeat requests appear.

Will slowing down Heartbeat stop autosave from working?

In the block editor, autosave runs through its own route, so slowing Heartbeat does not stop it. In the classic editor, autosave uses Heartbeat, so a longer interval means saves happen less often, not that they stop. Avoid disabling Heartbeat on the editor screen altogether if anyone still uses the classic editor.

Why do I see heartbeat requests even when nobody is editing?

Any open dashboard tab keeps ticking, including one left open on a staff computer overnight, though background tabs tick less often. A plugin may also have added Heartbeat to the front end, or to a dashboard widget that stays open. Ask the team to close idle admin tabs and check the public site for front-end ticks.

Is a heartbeat setting in my caching plugin enough, or do I need code?

The setting is enough for most sites. Plugins such as WP Rocket, Perfmatters and LiteSpeed Cache let you allow, slow or disable Heartbeat in each location without touching code. Use code only if you want finer control, and never use both the setting and a code snippet at once, as they can work against each other.

When Heartbeat turns out to be only part of the story, a wider look usually helps. Our website speed optimisation service starts with an audit, background requests included, and any change is made with your approval and re-tested afterwards.

Next in this series: WooCommerce Site Slow? What to Fix First

Is Your Website Working Properly?

Get a free website health check from WebMaintor. We'll review your website's speed, security, forms, and technical health — and tell you exactly what needs attention.

No obligation. No automated reports. A real review by our team.