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: 0These 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
Items the destination confirmed as written.
Think “destination says it changed”.
Related: Applier
Items the destination confirmed as removed.
This only moves when removals are enabled for that feature.
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.
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.
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
Hard failures during the run.
This includes exceptions and unhandled HTTP failures.
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:
This happens when the destination snapshot you diff against lags behind reality.
Typical reasons:
Provider caching / eventual consistency The API accepts writes, but reads don’t reflect them immediately.
Snapshot caching inside CrossWatch CrossWatch may reuse an in-run snapshot for speed.
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.
If you see:
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:
Dry run is off.
The feature is enabled, and Add/Remove toggles are on.
Provider health is OK.
Related:
Debug level: Maintenance
Provider health gates: Health
Matching issues: Analyzer
Last updated
Was this helpful?
Was this helpful?
Total added: 0
Total removed: 0
Total skipped: 173
Total unresolved: 0
Total errors: 0
Total blocked: 0