Sync history
Read past cycles, find the one that failed, and see what it was carrying.
A run is recorded when an agent pushes captured changes, and when a cycle fails. The Sync history tab on a school is where you go once something looks wrong on the Overview.
The run list
| Column | Shows |
|---|---|
| Timestamp | When the cycle ran |
| Status | Success or Failed, with a green or red dot |
| Direction | UP or DOWN |
| Process | A compact summary of the tables and changes involved |
| Error | The message the agent reported, truncated, alongside a badge counting any conflicts |
| Duration | How long the cycle took |
Filters narrow by date range — All time, Last 24 hours, Last 7 days, Last 30
days — and by status, direction and whether the run produced conflicts. Search matches the
timestamp, the direction, the success or failure text and the word conflict, which is the
quickest way to pull up a run someone reported by time.
Selecting a run opens the full cycle, broken down per table, so you can see exactly which rows it was carrying.
Reading a failure
A failed run is not a dropped run. The agent stops at the first change it cannot apply and refuses to acknowledge past it, so the queue holds its position and retries on the next cycle. That means:
- One failure repeating every cycle is the normal shape of a blocked queue. Fix the cause and the backlog drains on its own.
- The error names the row. The Agent logs panel on the Overview tab carries the detail behind the truncated message.
- Nothing after it has been applied. Later changes are still queued, not lost.
The usual causes are a missing parent row on the receiving side, which apply order is meant to prevent, and a column that exists on one side but not the other after a schema change — the Schema tab confirms the second in a couple of clicks.
Conflicts on a run
A run can succeed and still carry a red conflict badge. The count belongs to the run that pushed the rows, not to the agent that refused them, so it can appear well after the run itself finished — the other side only reports back once it has tried to apply the change.
Those rows were not written anywhere. Filter by With conflicts to find the runs involved, then use the Conflicts tab to decide which version survives.
When there is nothing to show
An idle agent produces no runs at all. A cycle that finds no pending rows pushes nothing, and only a push or a failure creates a record here, so a quiet list is not evidence that anything is broken.
To tell a healthy idle agent from one that has stopped, read Last seen on the Overview. That updates every cycle, because the agent asks the server for its configuration whether or not it has work to do. A recent Last seen with no runs on a database that should be busy points at missing triggers rather than at the agent — check the Setup SQL has been run there.