Open your WordPress post editor, then check your browser’s Network tab. Every 15 seconds, you’ll see a POST request fire to admin-ajax.php. Open a second tab with the dashboard? Another request every 60 seconds. Three editors working simultaneously? That’s potentially 12+ requests per minute — all uncacheable, all requiring full PHP execution.
That’s the WordPress Heartbeat API. And on shared hosting, it’s one of the top reasons your hosting provider sends you “excessive CPU usage” warnings.
What is the Heartbeat API?
The Heartbeat API was introduced in WordPress 3.6 as a real-time communication channel between your browser and the server. Think of it as a pulse — every few seconds, your browser asks the server: “anything new?”
It powers several genuinely useful features:
- Auto-saving drafts while you write posts
- Post locking — warning you when another user is editing the same post
- Session management — keeping you logged in and warning when your session is about to expire
- Real-time notifications — dashboard alerts from plugins
The API works by sending AJAX POST requests to /wp-admin/admin-ajax.php at regular intervals. In the post editor, that interval is 15 seconds. On other admin screens, it’s 60 seconds. Some plugins also use the Heartbeat API on the frontend.
Why should you care?
Uncacheable server load. Every Heartbeat pulse is a POST request to admin-ajax.php. POST requests bypass all caching — page cache, CDN cache, everything. Each one requires a full WordPress bootstrap: loading the core, all active plugins, and the active theme. That’s real PHP execution and real database queries, 4 times per minute per editor.
The math gets scary fast. One editor with the post editor open generates 4 requests per minute (every 15 seconds). Leave it open for an hour — that’s 240 requests. Five editors in a newsroom? 1,200 requests per hour from Heartbeat alone. On shared hosting where you might have 10-20 PHP workers total, this dominates your available capacity.
It runs even when you’re idle. Step away from your desk with the editor open? Heartbeat keeps pulsing. WordPress does throttle it after an hour of inactivity, but that’s still 60 minutes of unnecessary requests. If you leave a dashboard tab open overnight, that’s hundreds of wasted server hits.
It’s the top admin-ajax.php offender. When hosting providers flag high admin-ajax.php usage, the Heartbeat API is the first suspect. I’ve seen shared hosting accounts suspended because an admin left multiple editor tabs open for days.
The quick fix
You have two approaches — throttle (recommended) or disable:
Option 1: Throttle to 60 seconds everywhere
// Slow down Heartbeat to 60-second intervals
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60; // Maximum allowed: 120
return $settings;
});This keeps auto-save and post locking working but reduces requests by 75% in the editor (from every 15s to every 60s).
Option 2: Disable Heartbeat except in the post editor
// Disable Heartbeat on dashboard and frontend, keep in editor
add_action( 'init', function() {
// Allow Heartbeat in post editor for auto-save
global $pagenow;
if ( $pagenow !== 'post.php' && $pagenow !== 'post-new.php' ) {
wp_deregister_script( 'heartbeat' );
}
}, 1 );
// Throttle editor Heartbeat to 60 seconds
add_filter( 'heartbeat_settings', function( $settings ) {
$settings['interval'] = 60;
return $settings;
});This is the recommended approach for most sites: Heartbeat runs only where it’s actually needed (the editor) and at a reduced frequency.
Warning: Disabling Heartbeat in the editor means no auto-saves and no post locking. If you disable it everywhere, always manually save your work.
The one-click solution
OvKit includes Limit Heartbeat under Features → Performance with granular control: disable on the frontend, disable in the admin, and limit in the post editor — all independently configurable. The default setting keeps Heartbeat running in the editor at 60-second intervals while disabling it everywhere else.
What happens after you fix this?
- 75% fewer admin-ajax.php requests when editing posts (from 4/min to 1/min)
- Zero Heartbeat requests on the dashboard if disabled there
- Zero Heartbeat requests on the frontend — no impact on visitor experience
- Significantly lower CPU usage — especially noticeable on shared hosting
- Hosting provider warnings stop — your account stays in good standing
FAQ
Will disabling Heartbeat cause me to lose unsaved work?
If you disable Heartbeat in the post editor, yes — auto-save stops working. This means if your browser crashes or you close the tab without saving, your changes are lost. The safer approach is to throttle (slow down) Heartbeat in the editor rather than disabling it entirely. At 60-second intervals, you still get auto-saves every minute with 75% less server load.
Does the Heartbeat API affect my site’s frontend speed?
Only if a plugin uses Heartbeat on the frontend. By default, WordPress only uses Heartbeat in the admin area. However, some plugins (like certain live chat or notification plugins) can register Heartbeat scripts on the frontend. If you’re seeing admin-ajax.php requests in your frontend Network tab, that’s a plugin adding frontend Heartbeat. OvKit lets you disable this specifically.
I use WP Rocket — should I use its Heartbeat Control instead?
Use one or the other, not both. WP Rocket’s built-in Heartbeat Control does the same thing — it lets you reduce activity or disable Heartbeat per area. If you already have WP Rocket managing this, you don’t need a separate solution.
Related reads: