Jump directly to the Phase 1 — Immediate Triage section below. Do not skip to the recovery steps before completing triage — acting on incomplete information is the primary way data loss happens during sync recovery. The five minutes you spend on triage will prevent hours of cleanup later.
A broken user sync is one of those problems that feels worse the longer you look at it. The moment you confirm that sync has failed, you are simultaneously aware that every user registration, profile update, and password change that occurred during the failure window may not have reached all of your connected sites. You do not know the full scope yet. You do not know exactly when the failure started. And your instinct is to do something immediately — to run a fix, to push a sync, to restore a backup — before you have enough information to do any of those things safely.
That instinct is the most dangerous thing about sync recovery. Acting on incomplete information — running a Bulk Push before you understand the current state of each site, restoring a backup before you understand which data is authoritative, clearing the queue before you have extracted the events it contains — is how a recoverable situation becomes a data loss event. The order of operations in sync recovery is not a formality. It is what separates a clean recovery from one that leaves permanent gaps in your customer database.
This guide provides the complete ordered recovery framework. It covers four phases: immediate triage to understand the scope, damage assessment to map exactly what went wrong and when, systematic recovery to restore sync without overwriting good data with bad, and verification to confirm the recovery was complete. We cover this in the context of WordPress multi-site user sync recovery tools and the specific capabilities they provide for each phase.
This guide is written with the assumption that you have a sync system in place that has stopped working correctly. If you are setting up sync for the first time, this guide will still give you important knowledge about how to design your setup to be recoverable — but the immediate focus is on broken sync recovery.
Phase 1: Immediate triage — the five things to do before anything else
Triage is about establishing situational awareness before taking action. The goal of this phase is not to fix anything. It is to gather enough information that when you do act, you act correctly. Every step here takes minutes. Every step skipped adds potential hours to the recovery.
Open the event log in your sync plugin. Find the most recent event marked as “completed” or “applied” with a confirmed successful outcome. Note the timestamp. This is the end of your last known-good sync state. Everything after this timestamp is the failure window — the period during which user events may not have propagated correctly. Write this timestamp down before doing anything else.
Before touching anything, back up the current state of every site’s database. This is not a recovery step — it is insurance. If any subsequent action during recovery produces unexpected results, you need to be able to return to the exact state the databases were in when you started. A backup taken now preserves the current (imperfect) state. A backup taken after an incorrect recovery action preserves a worse state. Do this before step T3.
A broken sync that continues to process events during your investigation can compound the damage. If partial or incorrect data is being written to sub-sites by a malfunctioning sync system, those writes will make your recovery harder. Pause the sync queue processor by disabling the relevant scheduled cron event, or by temporarily disabling the sync plugin, before proceeding with assessment. Note the exact time you paused it — you will need this for your failure window documentation.
The sync queue contains a record of every user event that occurred during the failure window and has not yet been successfully delivered. This is potentially the most valuable information you have for recovery. Export or document the current queue contents — event types, user IDs, timestamps, and destination sites — before anything clears or modifies it. If the queue is cleared automatically by any recovery action you take later, you need this record to understand what events need to be manually addressed.
Not every failure affects every connected site equally. A sub-site that was down during a partial failure may be missing data that other sub-sites received. A failure that affected event creation (not just delivery) will have missed all events regardless of destination. Identify which sub-sites have data that diverges from the master, and in what direction — are they missing records entirely, or do they have stale versions of records that were updated on the master?
The master site’s database is your source of truth. Everything in recovery points back to this principle. When there is a conflict between what the master site holds and what a sub-site holds, the master site wins. When you are unsure whether to push data forward or pull data back, you push from master to sub-sites. Any action that overwrites master site data with sub-site data should require explicit, documented justification before it is taken.
Phase 2: Damage assessment — mapping exactly what went wrong
With triage complete, you now have a failure window (T1), database backups (T2), a paused sync system (T3), a record of queued events (T4), and a map of affected sites (T5). Phase 2 uses this information to answer three specific questions whose answers will determine your recovery strategy.
Cross-reference the failure window timestamps with your user registration logs on the master site. How many new users registered between the start of the failure and when you paused sync? How many existing users updated their profiles during that window? These numbers define the scope of the recovery operation and determine whether you can address it manually for specific users or need to run a full automated resync.
On the master site: SELECT COUNT(*) FROM wp_users WHERE user_registered BETWEEN '[failure_start]' AND '[pause_time]' gives you the new registrations. The sync plugin’s event log (filtered by date range) gives you profile update events. Export both lists with user IDs and email addresses.
This is the question that determines whether you have a simple “push missing data forward” recovery or a more complex “reconcile conflicting versions” recovery. If users could update their profiles on sub-sites during the failure window — and those updates were not propagating back to the master because sync was broken — then sub-sites may hold newer data for some fields than the master does. A blind Bulk Push from master to sub-sites in this scenario would overwrite those newer sub-site updates.
On each sub-site: query wp_users for records where user_modified falls within the failure window. Any sub-site user record modified during the failure window that also has a corresponding modified record on the master site needs field-level reconciliation before you push.
You cannot safely restore sync until you have identified and fixed the root cause. If you restore sync without fixing the underlying problem, the same failure will recur — potentially while you are in the middle of the recovery operation. Use the failure mode taxonomy from the queue failure monitoring guide to identify the specific cause: cron stall, sub-site connectivity, API key invalidation, or another root cause. Confirm the fix before moving to Phase 3.
Enable WP_DEBUG_LOG on the master site and attempt a manual single-event sync for a test user. Read the debug log for the specific failure message. Cross-reference with the queue failure modes to identify the root cause. Fix the root cause and confirm a test sync succeeds before proceeding.
Phase 3: Systematic recovery — the correct sequence for restoring data integrity
Recovery sequence matters more than speed. The steps below are ordered deliberately — each one creates the conditions the next one requires. Skipping steps or changing the order introduces risks that the sequence is specifically designed to eliminate.
The Bulk Push: what it recovers and what it cannot
The Bulk Push is the primary recovery tool for most sync failure scenarios, but it has specific capabilities and specific limitations. Understanding both prevents over-reliance on it and ensures you address the gaps it cannot fill.
- User accounts that exist on master but not on sub-sites — created on all sub-sites
- Core profile fields (email, display name, username) — synchronized to current master state
- WooCommerce billing and shipping metadata — delivered to all connected stores
- Extended profile metadata configured for sync — delivered in current master state
- Current user roles — delivered via role mapping to all sub-sites
- User accounts that were deleted on master — deletion propagated to sub-sites
- Incremental history — only delivers current state, not the sequence of changes that led to it
- Sub-site modifications made during the failure window — will overwrite them unless R2 was completed first
- Password changes made on sub-sites during the failure window — will overwrite with master’s current hash
- User accounts that existed only on sub-sites and never on master — these are outside the push scope entirely
- Order or activity data tied to user accounts — Bulk Push is for user record sync only, not transactional data
Phase 4: Verification — confirming the recovery is complete
Recovery without verification is not finished recovery. Every assumption you made during the recovery process needs to be tested against actual data before you close the incident. This phase is not optional and it is not a formality — it is where you find the gaps that the recovery process missed.
Select 10 to 20 users who registered or updated during the failure window. For each one, compare their record on the master site to their record on every connected sub-site. Email, display name, billing address, and shipping address should match exactly. Any discrepancy identifies a user who was not fully recovered and needs individual attention.
Query each sub-site for user counts registered within the failure window and compare to the master site count. On the master: SELECT COUNT(*) FROM wp_users WHERE user_registered BETWEEN '[start]' AND '[end]'. Run the equivalent on each sub-site. If the counts differ, the missing users need to be identified by email and their records pushed individually.
Trigger a test profile update on a live user account on the master site. Verify it appears in the queue immediately, processes within the expected time window, and arrives correctly on all sub-sites. Check the event log entry for the test event — it should show “applied” status with a successful outcome for every connected sub-site. This confirms the live sync is healthy, not just the recovery of historical data.
Check the event log failure count at 24 hours and 48 hours after resuming live sync. A healthy recovered system should produce a failure rate comparable to pre-incident levels. An elevated failure rate in the first 48 hours indicates a residual issue that needs to be addressed before the incident can be fully closed.
Post-mortem: preventing the same failure from recurring
Every sync failure is an opportunity to eliminate a category of future failure. A post-mortem conducted within 48 hours of recovery — while the details are fresh — produces the specific configuration changes and monitoring improvements that reduce the probability of recurrence.
Record: the exact failure start time, the root cause, how it was detected (customer complaint vs. proactive monitoring), the recovery steps taken, and how long the recovery took. This document becomes the reference for your monitoring improvements and for communicating with your team if a similar failure occurs.
If the failure was detected via customer complaint, identify which monitoring signal would have flagged it proactively. Add that check to your daily or weekly monitoring routine. Most failures produce detectable signals 30 to 120 minutes before any customer reports a problem. Add the signal that was absent.
If the failure lasted longer than the interval between database backups, and if recovery required comparing current state to a known-good state, your backup frequency was insufficient for your risk tolerance. Adjust the backup schedule so that the maximum failure window that could occur between backups is acceptable to your business.
Some failure modes expose underlying architectural risks: a cron stall on a low-traffic site suggests moving to a system cron instead of WordPress pseudo-cron. An API key invalidated by a backup restore suggests a key rotation procedure that includes sync reconfiguration. A WAF blocking sync traffic suggests a connection architecture that does not rely on the WAF being correctly configured. Address the architectural risk, not just the symptom.
The complete recovery reference: a single-page summary
Sync failures are recoverable. The outcome depends almost entirely on how quickly the failure is detected and how systematically the recovery is executed. An organization that detects a failure within 30 minutes and follows a documented recovery process will recover completely, with zero data loss, in a matter of hours. An organization that discovers the failure days later and responds reactively will spend days in recovery and may not fully close all the gaps.
The tooling you need for this recovery framework — the event log that establishes your failure window, the queue panel that documents pending events, the Bulk Push that restores user state, and the dashboard that confirms recovery health — is what Nexu User Sync’s WordPress multi-site recovery and data restoration tools provide as built-in capabilities. The process is yours. The infrastructure is there.
When sync breaks, recover completely. Every user. No data left behind.
Nexu User Sync provides the event log, queue visibility, Bulk Push recovery tool, and network health dashboard that every step of this recovery framework depends on — so when a failure occurs, you have the infrastructure to respond correctly.
The triage steps saved me hours of cleanup. worth reading before you panic
Oh man this saved me during a sync
This saved my job last night. step by step triage stopped me from making it worse.
Hi! this saved me during a sync disaster.