View sync status and logs

View sync status and logs

The Sync status page tells you honestly what the last sync actually did — and lets you act on any problems right there, without leaving the page.

Steps

Step 1 — Open Sync status {#step-1}

Select Sync status in the left sidebar.

Make sure you are in per-school mode (a school is selected in the switcher). In MAT mode, select a school first, or use the MAT sync overview button to see all schools at once.

Step 2 — Read the honest status header {#step-2}

The banner at the top of the page states plainly what the last sync run actually did — it never labels a run "failed" just because some individual changes didn't apply:

A N will retry badge next to the header means some errors are transient (rate limits, timeouts) and the engine will retry them on its own — no action needed. Run history opens Provisioning runs for the full run-by-run detail.

If a notification bell brought you here, it deep-links straight to this page — and for a specific issue, straight to that issue's row in the panel below (it opens and scrolls into view automatically).

Step 3 — Act on issues right here {#step-3}

Below the header, the Issues panel lists every outstanding problem the last sync couldn't apply, grouped by cause and sorted most-urgent first — e.g. "48× Add to classroom — Permission denied" — the same grouping the Logs page uses, so the two surfaces always agree.

Click a row to expand it and see the affected users, the actual error message, and the raw detail. Each row carries a badge for how urgent it is (Needs escalation / You can fix this / Known issue / Will retry) and an action strip:

• Fix — takes you to the existing screen that resolves that specific cause (e.g. the orphaned-classroom review, or the affected user's record). Never a fake button — if there's no real fix, you get guidance instead.
• Retry outstanding — re-queues the still-failing items through the normal sync engine. Safe to use any time (it re-checks current state, so re-running something already fixed does nothing).
• Ignore — hides the row (current instances, or the whole cause going forward) without deleting anything. Reversible any time via Show ignored → Un-ignore.

See Understanding and actioning sync errors for exactly what each badge and action means, and what "Failed 47 times, last seen…" tells you.

Fixing, retrying to a successful outcome, or ignoring a cause here clears it from this panel and from the notification bell — they read the same underlying data, so they can't disagree.

Step 4 — Check the integrations panel {#step-4}

Further down, the Integrations summary shows one tile per connected platform (Google Workspace, Microsoft Entra, etc.), with a badge that speaks the same honest language as the Issues panel above it:

Step 5 — Check the per-platform summary {#step-5}

Each enabled platform also has a summary card showing raw counts for the selected time window:

• Success — sync actions that completed without error
• Errors — actions that failed
• Other — informational events (e.g. skipped)

Change the time window (Last 24 hours / Last 7 days / Last 30 days) using the dropdown in the top-right corner.

Trend over the window {#trend}

The Trend card plots errors per day across the window alongside the success rate, so you can see at a glance whether sync health is improving or degrading — click a bar to open that day's errors in Logs. The home dashboard's Sync centre shows the same as a compact 14-day sparkline, and the MAT sync status page shows a trust-wide trend across all your schools.

Step 6 — Review the activity log {#step-6}

The Recent activity panel (collapsed by default, below the Trend card — click to expand) lists individual sync events:

Step 7 — Deeper triage on the Logs page {#step-7}

The Logs page (in the sidebar) uses the same grouped-error view as the Issues panel above, but across a wider window and with more filters — reach for it when you need to search or filter beyond what's outstanding right now.

Two view modes sit next to the search box, so switching between them is one click — no need to open Filters:

• Grouped (default) — errors folded into one row per root cause, with the affected users, the badge and the Fix / Retry / Ignore actions.
• Table — one row per individual log entry: when, source, action, who it affected, and the outcome. Use this when you want the raw feed — to scan chronologically, to check a specific run, or to read successes and skips alongside errors. Where a failure kept repeating, the row shows its most recent time plus a ×N count, so a persistent problem never looks like a one-off.

Switching mode moves the Outcome filter with it, because the two answer different questions: Table shows all outcomes (the whole story, successes and skips included), and Grouped goes back to Errors (grouping by cause only applies to failures). Pick an outcome by hand afterwards and it stays put.

The view you pick is part of the page address, so you can bookmark or share a link straight to the table view.

Use the filters to narrow results:

• Platform: all platforms that have activity (Google Workspace, Microsoft Entra, Active Directory)
• Outcome: Errors (default) / Success / Skipped (unchanged) — skips are hidden by default because they are normal "nothing changed" events
• Time window, Action (e.g. Add to classroom), User (username), free-text Search, and Sort

To investigate a specific user, type their username into the User filter.

Step 8 — See provisioning runs {#step-8}

For a higher-level view, open Provisioning runs (the button in the top-right of the Sync status page, or Run history next to the status header). Where the activity log lists individual events, this page groups them into runs — one execution of a scheduled command or an admin-triggered sync:

• In progress — runs happening right now. This panel refreshes automatically, so after you trigger a manual sync you can watch it run here. Use Pause live to stop the auto-refresh.
• Last run per command — the most recent run of each command, with its status, how long it took, and what it changed (e.g. "5 updated · 1 error").
• Recent runs — a feed of completed runs, filterable by command and by status (Success / Failed / Skipped). The Detail column shows the error or the reason a run was skipped.

"Skipped" is normal — it usually means the school was outside its provisioning date window, or a sync option is turned off for that school.

Step 9 — See the live queue {#step-9}

Open Queue (under Sync status) to see the sync work queue in real time — the jobs the provisioning service has waiting or in-flight, rather than the runs that have already finished:

• Running now — jobs a worker is processing this moment (auto-refreshing; use Pause live to stop).
• Queued — jobs enqueued and waiting their turn.
• Recently completed — jobs that just finished or failed, with how long they took.

A per-integration summary shows how many Google / Microsoft jobs are running or queued. In MAT Overview the Queue is trust-wide (all your schools, plus shared infrastructure jobs); per school it shows only that school's jobs.

Step 10 — See when things run {#step-10}

Open Schedule (under Sync status) to see when each sync task runs — the MIS fetch, the Google and Microsoft provision passes, and housekeeping — with its cron timing and the next time it is due. Filter by integration to answer "when does Google next sync?" without asking an engineer. The list is published by the provisioning service itself, so it always matches what actually runs.

See what the origin says

The logs show what the sync did. To see what the source says — the MIS, via Wonde — open Wonde data; it helps you tell whether a problem is in the source data or the sync. Match the MIS ID shown there against the logs.

Troubleshooting

• "I see errors but the users look fine in Google" — some errors are transient (temporary API failures that succeed on retry). Check whether the same user shows later successes.
• "The log is empty" — try extending the time window to Last 7 days. If still empty, syncing may not have run or no platforms are connected.
• "I see errors for a specific user" — see User not syncing — troubleshooting.
• "The header says 'Sync failed' but I only see a handful of old errors" — "Sync failed" only ever means the scheduled run itself aborted, never that some individual changes had problems; if you're seeing that header, check Provisioning runs for what actually happened.

Related

• Understanding and actioning sync errors
• How syncing works
• Trigger a manual sync
• User not syncing — troubleshooting
• Wonde data — view your origin data