Sync statuses
Meaning of added, removed, updated, skipped, blocked, unresolved, errors, and sync summary counters.
CrossWatch reports sync statuses during planning, apply, and summary output.
Use this page to read a run quickly.
Read a sync in this order:
Plan or attempted tells you what CrossWatch tried.
Added, removed, and updated tell you what changed.
Skipped, blocked, unresolved, and errors explain why the rest did not change.
Quick status guide
added
CrossWatch created the item on the destination.
No
removed
CrossWatch deleted the item on the destination.
No
updated
CrossWatch changed an existing destination item.
No
skipped
CrossWatch intentionally did nothing.
Usually no
blocked
CrossWatch filtered the item before writing.
Sometimes
unresolved
CrossWatch could not match the item on the destination.
Yes
errors
The operation failed or could not complete reliably.
Yes
Changed statuses
Added
The item was added to the destination provider.
Examples:
a movie was added to a watchlist
a rating was created
a history entry was written
playback progress was created
An item counts as added only after the destination confirms the write.
Removed
The item was removed from the destination provider.
Examples:
a movie was removed from a watchlist
a rating was deleted
a playlist item was removed
After a removal, CrossWatch can store a tombstone.
That helps stop the same item from being re-added immediately in a later run.
Updated
The destination already had the item, but CrossWatch changed it.
Examples:
a rating value changed
playback progress changed
an existing history record was updated
playlist metadata changed
Run counters
Attempted
Attempted is the number of items CrossWatch sent into a provider operation.
It does not guarantee that the destination changed.
Some attempted items can later end up as skipped, blocked, unresolved, or errors.
Example:
Confirmed
Confirmed means the destination provider reported a successful result.
In normal summaries, confirmed items are reflected as added, removed, or updated.
Confirmed is more reliable than attempted.
Plan
The plan is the set of changes CrossWatch calculated before writing.
It can include:
items to add
items to remove
items to update
Example:
The final result can differ from the plan.
Items can still be skipped, blocked, unresolved, or fail during apply.
Pairs
Pairs is the number of configured provider routes processed in the run.
A pair is a sync path between two providers.
Examples:
Pairs does not mean media item count.
No-change outcomes
Skipped
CrossWatch intentionally did not apply the item.
Common reasons:
the destination already has the same value
there is no effective change
the destination does not support that item
required information is missing
sync rules exclude the item
the provider returned a no-change result
Skipped is usually not an error.
No change
No change means CrossWatch checked the item and the destination already matched the expected state.
No provider change was needed.
Depending on the provider and feature, CrossWatch can report this as skipped, no change, or no operation.
No operation
A no operation result, sometimes shown as NOOP, means the provider accepted the request but changed nothing.
Examples:
deleting an item that was already absent
adding an item that already existed
updating an item with the same value
A no-operation result is normally not an error.
Problem outcomes
Unresolved
CrossWatch could not match the item to a valid destination item.
Common reasons:
no supported provider ID was available
the destination provider could not find the item
title and year did not produce a safe match
the media type did not match
the provider was temporarily unavailable
the provider returned incomplete metadata
Unresolved usually means you should inspect IDs, metadata, or provider state.
Use Analyzer when the same item keeps returning as unresolved.
Advanced: unresolved state files
CrossWatch can store unresolved items under /config/.cw_state/ so later runs can avoid retrying the same bad write immediately.
A pending file can look like this:
An unresolved record can include a canonical key, title, year, media type, provider IDs, failure reason, and timestamp.
Blocked
CrossWatch excluded the item before it sent the write to the destination provider.
Blocked does not mean the destination rejected it.
It means CrossWatch filtered it first.
Common sources:
a tombstone from an earlier removal
a previous unresolved item
an internal blackbox entry
cross-feature unresolved blocking
Advanced: why items get blocked
Previously removed
The item matches a tombstone from an earlier removal.
This helps prevent immediate re-add loops in two-way sync.
Previously unresolved
The item failed earlier and is temporarily held back.
This reduces repeated retries for the same bad match.
Blackbox
The item is in an internal blocklist because repeated processing is known to fail or behave badly.
Cross-feature blocking
An unresolved item from one feature can block the same canonical item in another feature.
Example: a watchlist unresolved item can later block a progress add.
Errors
An error means the operation failed or could not complete reliably.
Common causes:
provider API errors
authentication failures
rate limits
network failures
invalid provider responses
unexpected data formats
internal processing exceptions
Errors are different from unresolved items.
Unresolved means CrossWatch processed the item but could not match it safely.
Errors means the write or provider interaction itself failed.
How to read the final summary
CrossWatch can show a compact summary like this:
The symbols mean:
+
Added
-
Removed
~
Updated
The counters add context:
pairs
Provider pairs processed
skipped
Items intentionally not changed
unresolved
Items that could not be matched
errors
Operations that failed
blocked
Items filtered before provider processing
Example interpretation
This means:
CrossWatch tried to process 15 items.
10 were confirmed as added.
2 needed no effective change, or were intentionally skipped.
1 could not be matched safely on the destination.
2 were filtered before any provider write.
no provider or processing errors occurred.
When to act
Mostly added, removed, or updated — the run behaved normally.
Mostly skipped or no change — the destination was already aligned.
Repeated unresolved — fix IDs, title/year quality, or matching inputs.
Repeated blocked — inspect tombstones, unresolved state, or blocklist behavior.
Any errors — inspect Debug output and provider health first.
Related topics
Last updated
Was this helpful?