Sync results

What the Done counters mean after a sync run.

When a sync run finishes, you’ll often see a summary like this:

[i] Done. Total added: 0, Total removed: 0, Total skipped: 173, Total unresolved: 0, Total errors: 0, Total blocked: 0

These numbers are totals for the whole run.

They are not “per pair” or “per feature”.

To drill in, use the run log events.

Related: Eventing

What each number means

added

Items the destination confirmed as written.

Think “destination says it changed”.

Related: Applier

removed

Items the destination confirmed as removed.

This only moves when removals are enabled for that feature.

skipped

Items that ended as a safe no-op.

That usually means “attempted, but nothing was confirmed”.

Common causes:

• The item is already present on the destination.

• The destination reports “duplicate / already exists”.

• CrossWatch policy suppresses a write because it would be wrong.

• The destination returns ok, but no confirmations.

So a big skipped number is not automatically bad.

Example: why show/season “roll-ups” can be skipped

Some sources emit synthetic “show/season roll-up” items for history.

Some destinations only accept movie/episode history.

Writing roll-ups can cause perpetual diffs.

It can also mark too much as watched.

unresolved

Items CrossWatch tried to write, but couldn’t confirm.

Typical reasons:

• The destination can’t map the IDs (not_found).

• The payload can’t be built safely (missing IDs).

• The destination is down or timing out.

Unresolved usually means: “we tried, but the destination can’t process it”.

Related: Unresolved

errors

Hard failures during the run.

This includes exceptions and unhandled HTTP failures.

blocked

Items CrossWatch did not attempt because a guardrail blocked them.

Common blockers:

• tombstones (recent deletes)

• blackbox cooldown (repeated failures)

• unresolved-based suppression (don’t hammer known-bad keys)

• watchlist phantom guard (adds that don’t “stick”)

• mass delete protection (removal waves suppressed)

In the log, look for:

• blocked.counts

• mass_delete:blocked

Related:

• Blocklists

• Guardrails

• Phantom Guard

---

Why 2–3 runs can be needed to “settle”

This happens when the destination snapshot you diff against lags behind reality.

Typical reasons:

1. Provider caching / eventual consistency The API accepts writes, but reads don’t reflect them immediately.

2. Snapshot caching inside CrossWatch CrossWatch may reuse an in-run snapshot for speed.

3. Derived presence / roll-up suppression Some “presence” is inferred after the destination history is readable.

Related:

• Snapshot behavior: Snapshots

• Why reads look stale: Caching layers

• Advanced knobs: Runtime

If you see “changes” on run #1, then “skipped” on run #2, that’s often normal.

Reading the example output

If you see:

Total added: 0
Total removed: 0
Total skipped: 173
Total unresolved: 0
Total errors: 0
Total blocked: 0

Means:

• The run ended with no confirmed writes.

• CrossWatch treated 173 items as safe no-ops.

• Nothing failed hard.

• Nothing was blocked by guardrails.

If you expected real writes, check:

1. Dry run is off.

2. The feature is enabled, and Add/Remove toggles are on.

3. Provider health is OK.

Related:

• Debug level: Maintenance

• Provider health gates: Health

• Matching issues: Analyzer