WordPress’s Heartbeat API sends a small request to the server roughly every 15 to 60 seconds while wp-admin, and sometimes the front end, is open in a browser tab, powering things like autosave, post-locking, and real-time plugin notices. Left at its default frequency across many open admin tabs, or many concurrent editors, it can generate a steady stream of background load that has nothing to do with actual visitor traffic.
Heartbeat exists for real reasons, so throttling isn’t just turning it off
Autosave protects against losing work in progress. Post-locking prevents two people editing the same content at once. Some plugins use Heartbeat for genuinely real-time features like live order notifications.
Throttling it too aggressively, or disabling it everywhere, can quietly break one of those without an obvious error message pointing back at the cause — the feature just stops working, and nothing in the interface tells you why.
That’s why this is a tuning exercise rather than a single switch: the right frequency for a busy editorial team saving drafts constantly is different from the right frequency for a site with one occasional admin user.
Shared hosting adds a further wrinkle worth naming: on a resource-constrained plan, Heartbeat load from your own admin activity can compete with the resources your visitors’ page loads need, so the benefit of tuning it well is sometimes bigger than the admin-only framing suggests, particularly for a store that keeps several staff logged in throughout the working day managing orders and content simultaneously.
It’s also worth mentioning that Heartbeat frequency can usually be adjusted without touching any plugin code directly, which means this is a configuration change rather than a development project, and one that’s straightforward to revert if a particular setting turns out to be too aggressive for how your team actually works.
Heartbeat API throttling
WordPress pings your server constantly while wp-admin is open, and the default frequency can add up with several editors working at once. We tune it without breaking autosave or real-time features.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
What we need from you
- Roughly how many people regularly work in wp-admin at once
- Whether autosave frequency currently matters to your workflow
- Any plugin you know relies on real-time updates (live chat, order alerts, collaborative editing)
- Whether the slowdown is on the front end, the admin, or both
This or something else?
| Server load or CPU usage spiking while admin tabs sit open and idle | This fix covers it |
| Heartbeat specifically flagged in a monitoring tool or hosting dashboard | This fix covers it |
| Autosave or post-locking behaving oddly after a previous throttling attempt | This fix covers it |
| General slow admin unrelated to background requests | Slow admin dashboard fix |
| General site slowness with no admin-specific pattern | Slow site diagnostic report |
What we do
- Identify what’s actually using Heartbeat on your site — core features and any plugins
- Confirm which of those genuinely need frequent updates and which don’t
- Set Heartbeat frequency per context — editor screens, front end, other admin pages — rather than one blanket setting
- Disable it entirely where nothing on that screen actually depends on it
- Test autosave, post-locking and any real-time plugin features after the change
- Confirm server load actually drops with admin tabs left open, not just in theory
What is included
- Heartbeat frequency tuned per context rather than switched off blindly
- Autosave, post-locking and real-time features tested and confirmed still working
- A note on what was throttled and why, so a future developer understands the setup
- The pre-change backup, kept for 30 days
Not included
- Disabling autosave entirely, unless you specifically want that trade-off
- Fixing a plugin that’s poorly built around Heartbeat regardless of frequency
- Ongoing adjustment as new plugins are added
- General admin performance work unrelated to Heartbeat specifically
Questions about this fix
Will this break autosave?
Not if configured correctly — the aim is a sensible frequency, not disabling it. We test autosave specifically afterwards because it's exactly the kind of feature that fails silently if throttled too aggressively.
Why does this only seem to matter with several people editing at once?
Because each open browser tab running Heartbeat adds its own stream of requests, so the load scales with how many editors are active simultaneously, not with your site's visitor traffic.
Can I just disable Heartbeat completely?
You can, and some sites do, but it removes autosave, post-locking and any plugin feature relying on it sitewide. We'd rather tune the frequency to what you actually need than remove functionality wholesale.
Does this affect front-end visitors?
Usually not directly, since Heartbeat mostly runs in wp-admin, though some plugins do run a front-end version for logged-in users — we check for that specifically rather than assume it's admin-only.
How do I know if Heartbeat is even my problem?
Server load that correlates with admin tabs being open, rather than with visitor traffic, is the clearest sign — if your host or monitoring shows that pattern, it's worth mentioning when you order.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.