This page is intentionally text-only on demo2: the Sync Monitor has no populated profiles, cycles, conflicts or record ledger to illustrate. An empty board would show navigation without proving any of the operational states described below.
Watching sync run is an operations job, so it has an operations home: Sync Monitor, at Setup → Platform Operations → Monitoring → Sync Monitor, with a Health tab ("is anything wrong?") and a Conflicts tab ("what needs a decision?"). Each sync profile's own detail page carries the same panels scoped to itself, plus its cycle history and per-record ledger.
The Health board
One row per profile. The columns, and what each is actually telling you:
| Column | What it means |
|---|---|
| Status | The profile lifecycle: Draft, Seeding, Active, Paused or Failed |
| Watermark lag | How long ago the oldest active cursor advanced. Judged against the profile's own schedule — a nightly profile is not flagged for being an hour old. Never run means no cursor exists yet, which is a brand-new or never-seeded profile, not a healthy one |
| Last cycle / result | When the last cycle ran and how it ended: Running, Succeeded, PartiallyFailed, Failed or Cancelled |
| Failed streak | Consecutive failed cycles. One failure is noise; a streak is an outage |
| Open conflicts | Records frozen awaiting a human decision (see below) |
| Parked / deferred | The monitor separates records held by a conflict or error from records deferred while a reference is unresolved. On the Sync Profiles list, however, the single Parked records total aggregates Conflict, Error and Deferred states; use the monitor when you need the distinction |
| Reseed required | Entities whose incremental position cannot be trusted — no completed baseline stands behind the cursor — so "nothing changed" means nothing until they are reseeded |
| Sites | Only for push-based systems (such as Tally), where a client inside the customer's network sends the data. A site that stops reporting produces no run and no error — this column is the only place that silence becomes visible |
The Needs attention filter collapses all of that into the day's worklist. From a row, Open conflicts jumps to the Conflicts tab scoped to that profile.
The Conflicts inbox
A conflict is a record the engine refused to decide for you. Each row carries a kind:
| Kind | What happened |
|---|---|
| Both changed | Both systems changed the same field(s) since the last sync |
| Delete vs update | One side deleted the record while the other edited it — always a human decision, under every policy |
| Duplicate key | An outbound write collided with an existing external record's key |
| Reference unresolved | The record points at something that has no synced counterpart |
| Validation rejected | The receiving side refused the write — including guards such as re-opening a record in a terminal status |
Expanding a row shows only the contested fields, three columns side by side: the base value at last sync, the xMatix value, and the external value — with the sides that moved highlighted. That is the whole decision, laid out.
Resolution actions, per row or in bulk (Resolve selected, with a note stored against your user):
- Keep xMatix — the xMatix values for the contested fields are pushed out on the next cycle; the external edit is discarded.
- Keep external — the mirror image: the external values are written into xMatix.
- Merged by hand — you reconciled the values yourself in the records; the engine writes nothing, and if the sides still disagree the conflict reopens next cycle.
- Ignore once — closes the conflict without writing; the record keeps syncing and will reopen if the disagreement persists.
- Ignore always — closes the conflict and parks the record as Excluded, stopping it from syncing in either direction until someone selects Resume on the profile's Records tab.
A conflict's detection count is a queue-age signal: the engine keeps one open conflict per record and bumps the count each cycle the disagreement is re-seen — a high count means the record has been blocked for that many cycles while nobody decided.
The Records tab: per-record state
The profile's Records tab is the ledger explorer — the pairing between each xMatix record and its external counterpart. Record statuses: In sync, Pending out, Pending in, Conflict, Error, Deferred, and Excluded (parked). Search by either side's key to answer "what is the sync doing with this exact record", and use Resume to un-park an Excluded record.
Reading a failed run
Sync cycles execute as integration runs, so diagnosis drills from the profile into the Hub:
- On the profile's Cycles tab, find the failing cycle. Its counters — records in/out, echoes dropped, conflicts opened, deferred, failures — usually name the symptom already.
- Open the owning integration app and check the Errors tab (the run list pre-filtered to Failed and DeadLettered). Every run carries its latest error; the error's category classifies it: a deterministic failure, a transient one (retried automatically with backoff before dead-lettering), retries exhausted, an orphaned run reaped by the sweeper, or an operator cancellation.
- Drill into the run's steps. Failed executions capture each executed step's input and output; successful executions do so only when the flow enables Capture step data. Values are secret-redacted, and the snapshots are retained for a configured window (30 days by default), so an older run can legitimately have no step data. When present, the snapshots show which step broke and with what data: credentials and reachability point at the connection, nulls after the mapping step point at field paths, a 4xx from the connector points at the external system, and a validation message means xMatix itself refused the write.
- Fix accordingly, then use Replay only when the original status is Failed, Succeeded, DeadLettered or Rejected. The original flow version must still exist, and replay needs either an explicitly supplied body or the original run's archived
InputJson. Dispatch resolves that version's flow definition and executes its currently active version, so a repaired mapping can apply to the retained payload. A run still inside its automatic retry window is not replay-eligible and should be left alone.
Auth failures are deliberately not auto-retried — a rejected credential cannot heal by retrying. They persist until someone rotates or fixes the credential.
Common questions
What is watermark lag, exactly?
Each synced entity and direction keeps a cursor: the position in the change stream up to which everything has been durably processed. Watermark lag is the age of the oldest such cursor on the profile. It is the primary health signal because it measures outcome, not activity — a profile can be running on time and still fall behind if its passes keep failing before the cursor advances.
Why does a profile show healthy cycles but sync nothing?
The usual causes: the sync identity's record security has narrowed what the engine can read (it syncs only what that user can see); every read is being dropped as an echo because nothing actually changed; or — for push-based systems — the client on the other side stopped sending, which is exactly what the Sites column exists to reveal.
Do conflicts block the whole sync?
No. A conflict freezes that record in both directions; every other record keeps flowing. That is also why the backlog deserves attention — each open conflict is one record standing still, and the detection count shows for how long.
PartiallyFailed — is that bad?
It means the cycle completed but some entities or records inside it failed; the succeeded portion is committed and cursors advanced only where work was actually done. Treat it as a pointer into the Errors tab rather than an outage — but a recurring partial failure on the same entity is a real fault to chase.