Monitoring a Sync

Once a sync has been triggered — whether by webhook, schedule, or manual trigger — it moves through a series of statuses before completing. This page explains what each status means, where to find it, and what a healthy sync looks like.

Sync statuses

Each sync run progresses through a defined set of statuses. Not every run passes through all of them — a run that fails during the fetch phase skips the processing statuses entirely.

Status	Meaning	What to do
`queued`	The sync has been accepted and is waiting to start. Typically lasts a few seconds.	Wait. If it stays `queued` for more than a minute, see Troubleshooting.
`fetching`	ExpoPlatform is actively requesting records from the source API.	Wait — normal. Duration depends on the number of records and the source's response time.
`paginating`	The fetch has multiple pages of results. ExpoPlatform is working through them in sequence, saving progress between pages.	Wait — normal for large datasets.
`processing`	All records have been fetched and queued. Workers are now creating, updating, or skipping records in ExpoPlatform.	Wait — the counts (created / updated / skipped / failed) will increment as each record is processed.
`completed`	The sync finished successfully. All records have been processed and the final counts are available.	Review the counts to confirm expected results.
`failed`	The sync encountered an unrecoverable error — typically an API connectivity failure or a credentials problem.	Check the Logs tab (System and Requests sub-tabs) for the error detail. See Troubleshooting.
`abandoned`	The sync exhausted all automatic retries after repeated processing failures. The subscription has been reset to idle and the next scheduled run will start fresh.	Check the Logs tab for the failure detail. Fix the root cause to prevent repeated abandonment.

Terminology in the admin UI:

In-progress: fetching, paginating, processing
Failed: failed, abandoned
Terminal (finished): completed, failed, abandoned

Where to check status

The quickest place to check sync status is the integration's page in the admin UI.

For most integrations: open the Auto Sync tab on the integration's page. It shows each recent run with its status, type, duration, and counts for processed records and errors. Click a row to expand per-run detail.

For multi-step integrations, the history lists Sync Jobs with step progress (for example, 2/3); expand a job to see its per-step progress.

For Visit specifically: Visit is webhook-driven, so it doesn't currently produce sync-run records that the Auto Sync tab can list. To check what happened during a Visit sync, use the Logs tab (Admin → Integrations → Visit → Logs). An upcoming release migrates Visit to scheduled polling, after which it gains a standard Auto Sync tab like every other integration.

What "healthy" looks like

A healthy sync run moves through its active statuses in a few minutes and ends with completed. The specific counts depend on how much has changed since the last run.

For a scheduled incremental run on an active event

Status progresses from queued → fetching → processing → completed within two to five minutes for most integrations
CDS may take five to twenty minutes because it pages through the full dataset regardless of how many records have changed
The updated and created counts reflect real changes in the source system
On a quiet overnight run you may see mostly skipped (unchanged) — this is expected
The failed count should be zero or very close to zero

For a full resync after first setup

The run stays in fetching or paginating longer because it retrieves all records, not just changed ones
Expect a high created count as records are imported for the first time
skipped (unchanged) will be near zero because there's nothing stored to compare against yet

Understanding skip rates

Skip rates vary depending on what's happening in the source system:

30–70% unchanged in incremental syncs — normal. This means ExpoPlatform already has the current version of those records.
100% unchanged — nothing has changed in the source since the last run. Expected overnight or outside registration windows.
High categoryMapping skip rate — configuration issue. Records are being excluded because their external category has no mapping. See Category Mapping.
High settings skip rate — a filter is excluding more records than expected. Check the integration's Data Filters or specific settings (like Visit's Registration State Filter).
Sustained non-zero failed count — genuine issue. See Troubleshooting.

Sync run stuck in `processing`

If a sync run stays in processing for much longer than expected — the fetch completed but the run never moved to completed — it can mean worker queues are backed up. If it persists, contact your API Manager for investigation.