When a Sync Falls Behind
A sync records how far it has got. Everything about diagnosing one comes back to that marker.
Where to find it
Architect Panel → Integration & Connections:
- Table Sync — the syncs and their recorded position
Architect Panel → Activity:
- Activity Log — the entries being replayed
- Error Log — failures during a run
The position marker
Each sync remembers the last audit entry it processed. A run picks up from there and works forward.
That single number explains most behaviour: a sync that is up to date has a marker near the end of the audit trail, and one that has fallen behind has an older one and a backlog to work through.
Falling behind is usually catching up
A sync that has been off — a scheduling problem, an unreachable instance, a maintenance window — is behind rather than broken. Left running, it works forward through the backlog and arrives.
Check the marker is moving before treating it as a fault. A marker that advances is a sync that is fine and merely slow.
A stuck marker is the real problem
If it is not moving, something is refusing. Common causes, roughly in order:
- A field added at one end and not the other.
- The far instance unreachable, or its key rotated.
- A value the destination rejects — a validation rule that differs between the two.
- A referenced record that does not exist at the destination.
It stops rather than skipping
When an entry cannot be applied, the sync does not step over it and carry on. That is deliberate, and it is the right choice: skipping would leave the two ends silently divergent in a way nobody would notice until somebody compared them by hand.
A stopped sync is a visible problem. A skipping sync is an invisible one, and invisible divergence is much worse.
Fix the cause, then let it resume
Do not move the marker past a failing entry to get things running again. It will work — and it discards a change that everybody will assume was applied. If the entry genuinely cannot be applied, understand what it was before deciding to skip it, and record that you did.
The audit trail must still hold it
A sync behind by longer than your audit retention has a gap it cannot replay. If retention on a synced datastore is short and a sync has been off for a long time, re-establishing from a fresh copy may be the only honest recovery.
That is an argument for keeping audit retention comfortably longer than any outage you would tolerate.
Watch the markers routinely
A sync failing is quiet — the destination simply stops changing, which looks identical to nothing having happened at the source. Check the positions periodically rather than waiting for somebody to notice stale data.
Worked example
A nightly check shows one sync's marker unchanged for two days. The error log names a field the destination does not have — a column added at the source on Monday. The field is added at the destination, the sync resumes on its own, and it clears two days of backlog in a few minutes.
Recommendations
- Check the marker is moving before diagnosing anything.
- Never skip past a failing entry to get it running.
- Keep audit retention longer than any outage you would accept.
- Monitor sync positions — failure is silent at the destination.