# Sync results

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](/blueprint-architecture/orchestrator/eventing.md)

### What each number means

#### added

Items the destination **confirmed as written**.

Think “destination says it changed”.

Related: [Applier](/blueprint-architecture/orchestrator/applier.md)

#### 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.

<details>

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

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.

</details>

#### 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](/blueprint-architecture/orchestrator/unresolved.md)

#### 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](/blueprint-architecture/orchestrator/blocklists.md)
* [Guardrails](/blueprint-architecture/orchestrator/guardrails.md)
* [Phantom Guard](/blueprint-architecture/orchestrator/phantom-guard.md)

***

### 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](/blueprint-architecture/orchestrator/snapshots.md)
* Why reads look stale: [Caching layers](/blueprint-architecture/orchestrator/caching-layers.md)
* Advanced knobs: [Runtime](/blueprint-architecture/orchestrator/runtime.md)

{% hint style="info" %}
If you see “changes” on run #1, then “skipped” on run #2, that’s often normal.
{% endhint %}

### 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](/crosswatch/maintenance.md)
* Provider health gates: [Health](/blueprint-architecture/orchestrator/health.md)
* Matching issues: [Analyzer](/crosswatch/tools/analyzer.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://wiki.crosswatch.app/getting-started/first-time-setup/what-do-you-need/syncing/sync-results.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.