FOLLOW-UP
After a deeper look, I found the following:
- A search for a database schema/ER model for Jetpack was fruitless. I understand that such a model would be involved because of all the options that can be turned on and off, but it would have been helpful.
- There were actually 70,000+ records that all had to do with deleting the records through the WordPress dashboard. There must have been several sync records per failed transaction deleted.
- In one resource I did find, it mentioned turning off auto sync, but I don’t see that as being available in the WordPress dashboard.
- Is there an article about the purpose of sync in Jetpack?
Hi @marjoriesdaughter
Thanks for the detailed follow-up. From what you’ve described, the first step I recommend is to reconnect Jetpack so that any stuck or excessive sync records can be cleared properly:
- In your site’s WP Admin, go to Jetpack → My Jetpack.
- Scroll to Manage Connection and click Disconnect Site from WordPress.com.
- Once disconnected, reconnect using your administrator account linked to WordPress.com.
This will refresh the sync process and ensure Jetpack only tracks relevant events going forward.
Regarding your question — the sync table stores data Jetpack uses to keep your site and WordPress.com in sync for features like stats, backups, and security. While it’s possible to remove records directly from the database, doing so without a proper sync reset can cause inconsistencies or leave behind orphaned data in other Jetpack-related tables. That’s why a reconnect is the safest first step.
Here’s more about Jetpack Sync and its role:
https://jetpack.com/support/what-data-does-jetpack-sync/
Let me know once you’ve reconnected so we can proceed.
Thank you for all the information!
- On the disconnecting and connecting, it turns out that Jetpack was never actually connected to the site. But, the article you provided had the answer. “It is important to note that Jetpack syncs all the data required by all of its features, whether they are activated or not, to Automattic’s servers.”
From this statement, I’m understanding that, while Jetpack wasn’t directly involved in the failed orders attack, it was creating records of each action taken on the site. I consider this a bug in the design of the system. It means that every time there is one of this type of attack, which is becoming more common, there will be an overrun for small business sites on their server space.
- Since the site started in the disconnected state, is the next step to connect it?
Follow up tweak to previous message.
It occurred to me that the statement from the resource says that the sync records are going to Automattic’s servers. The overrun records I found are in the site database on the client’s web host.
Thanks!
Hi @marjoriesdaughter,
Good catch on that distinction. Jetpack only starts syncing once it’s connected to WordPress.com — until then, it wouldn’t be creating or sending records to Automattic’s servers. What you’re seeing in the client’s database are the local queue tables Jetpack uses after a connection exists, which normally clear as data is synced. If the site never connected, then those rows likely come from another plugin’s logging rather than Jetpack.
If you want to be certain, the next step is to connect the site once. That will establish a clean sync state and clear out any backlog that belongs to Jetpack. You can always disconnect afterward if you don’t want to keep the connection active.
Thank you for the reply!
To be sure I understand correctly:
- Other plugins might use the table named [x]_jetpack_sync_queue to record record deletion?
- In order to connect my client’s site to Jetpack, they would need a Jetpack account?
Hi @marjoriesdaughter
Thanks for your patience here.
What is likely happening is that another plugin is making changes on your site, Jetpack is noting that and creating a corresponding record in the database, and then waiting for the send the event (sync) to our servers.
For the sync to work, your client will need a free WordPress.com account to connect Jetpack. Once they connect to WordPress.com, Jetpack will start sending the sync actions to our servers, and you should see the table size delete.
To start this process, I’d recommend deleting and reinstall Jetpack and having your client activate and connect Jetpack to WordPress.com.
Let us know when you have done that, and we can test the connection on our end and make sure the syncing is working properly. If it isn’t, we can then go from there.
Hi there, @marjoriesdaughter,
Do you have updates about that, do you still need help? We usually close inactive threads after one week of no movement, but we want to make sure we’re all set before marking it as solved. Thanks!
