The first sign of trouble
One of our client sites has had long standing performance issues that have persisted ever since we inherited it five years ago. The website runs Woocommerce, has hundreds of products and dozens of orders everyday. We continue to improve the site performance, typically in the process of putting out the next spot fire.
This next issue started with a single line in a slow query log: a killed MySQL query, over 20,000 characters long, aimed at a table called wp_jetpack_sync_queue. The query itself was simple in structure, a SELECT pulling event_id and event_payload for a list of specific event IDs, but the list of IDs it was trying to match was enormous. The server killed it before it could finish.
That single killed query was a symptom. The real issue was sitting underneath it.
How the problem came to be
Jetpack Sync is the mechanism that keeps a self-hosted WordPress site in step with WordPress.com, it tracks changes (posts, options, users, and more) and pushes them across in small batches on a regular schedule. Every change waiting to be sent sits in wp_jetpack_sync_queue until a scheduled cron job checks it out and clears it.
Under normal conditions this is invisible. A few hundred rows come in, a cron job runs every five minutes, the queue clears, nothing to see.
The problem starts when the queue grows faster than cron can clear it. Every time Jetpack tries to check out a batch, it builds a SELECT query with an IN (...) clause listing every event ID in that batch. That’s fine for a normal batch size. It stops being fine once the backlog balloons into the thousands, because the query itself becomes too large and too slow to execute. It gets killed before it can process anything.
That’s the where the problem comes from: a failed checkout doesn’t shrink the queue, it leaves it exactly where it was, adding whatever new events arrived in the meantime. Each cron run makes another attempt, with an even larger backlog than the previous one, each attempt is more likely to fail than the one before it. Once the site crosses that threshold, it doesn’t have the ability to recover on its own. It just keeps getting worse, five minutes at a time.
Diving into the cron event list, this is exactly what we found:
queue_size: 5008
queue_lag: 866587 seconds (~10 days)Cron itself was confirmed healthy, wp cron event list showed both jetpack_sync_cron and jetpack_sync_full_cron firing right on schedule, every five minutes. The scheduling wasn’t broken. The checkout query was simply too large to complete before something further backed up behind it.
The impact
A stuck sync queue causes two separate problems:
Database load. Every failed checkout attempt is still a real query that has to be parsed and partially executed before MySQL kills it. Repeated every five minutes, this adds sustained load to the server for no benefit, since nothing actually gets processed.
Stale sync data. With queue_lag sitting at roughly ten days, any Jetpack feature that depends on sync being current, security scanning context, stats, backups, and related data, was working from a picture of the site that was a week and a half out of date.
Neither of these announces itself loudly. The site doesn’t report a critical error but there was an increase in 502 errors. There is no error banner in wp-admin that tells us what is going on. It shows up as a line in a slow query log and, if left alone, as small but compounding drag on database performance.
The fix
The practical fix was to clear the backlog outright rather than let cron keep failing against it:
wp jetpack sync resetThis empties the queue and triggers Jetpack to perform a fresh full sync from a clean slate.
Why it works
The reset breaks the loop directly. With the queue back at zero, the next cron run has a normal, small batch to check out again, small enough for the IN (...) query to complete well within normal limits. Sync goes back to working the way it’s supposed to: quiet, incremental, and invisible.
What if you don’t have shell access on your server. Deactivating, and reactivating the Jet Pack plugin clears the related tasks from the cron list.
It’s worth clarifying what this does, and doesn’t fix. A reset clears the immediate backlog and stops the compounding failure, but it doesn’t explain what caused the queue to grow that large in the first place. If something on the site is generating an abnormal volume of trackable changes, faster than cron can process even under normal conditions, the queue can build up again over time.
To be clear, Jet Pack was a casualty and not the cause of this issue. There are other poorly written plugins that have a legacy application on the site that need to be replaced with some custom development work.
That’s a separate, ongoing piece of investigation with the site that will help us move beyond needing to clear the cron schedule.
How to test it
Immediately after running the reset, confirm the queue is actually clear:
wp jetpack sync statusLook for:
queue_size: 0
queue_lag: 0That confirms the backlog is gone. The more important test is what happens next. A one-time reset that immediately proves the queue can climb right back up isn’t a fix, it’s a delay. Watch it over the following hour:
watch -n 30 "wp jetpack sync status | grep -E 'queue_size|queue_lag'"queue_size should stay low and queue_lag should stay near zero as cron continues to clear normal batches every five minutes. If it starts climbing again at a similar rate, that’s the signal that something is actively generating excess sync events, and the next step is finding exactly what, rather than resetting again and treating the symptom on repeat.
The takeaway
A killed query in a slow query log is easy to dismiss as a one-off. In this case it was the visible edge of a queue that had been quietly falling behind for days, compounding on itself every five minutes. The fix itself was a single command, but knowing which command to reach for, and why, depended on understanding the mechanism underneath it. It was not just that sync which was behind, but why a backed-up queue makes its own recovery progressively harder the longer it’s left alone.
Do you have performance issues on your website. We can help. Get in touch today.