Understanding and actioning sync errors

The Sync status page and the Logs page both group identical failures into one cause — "Add to classroom ×48 — permission denied" — so you triage causes, not individual rows. Both surfaces read the same grouping, so they never disagree: fix or ignore a cause on either page and it clears from both, and from the notification bell. Each group carries an urgency badge, a still failing count and an action strip.

One cause is one issue. The headline counts on every page ("3 things to look at", the bell's "Sync completed with 3 issues to look at") count causes, not rows: a cause that failed 1,000 times is one thing to look at. The row's ×N chip and "Seen N times" line keep the scale visible without making it the headline.

The five badges

Fix

Fix never does anything new — it routes you to the remediation that already exists for that cause. The button names where it goes:

When several people are affected there is no single Fix button — expand the row and open each person from the list instead. After fixing, use Retry what's still failing to prove the fix without waiting for the nightly run.

Retry

Retry what's still failing re-queues the group's still-failing users/groups through the normal sync engine — the same queue every other change uses. It's safe and idempotent: the engine reconciles current state, so retrying something already fixed does nothing. Attributed in the logs. Needs Run syncs & provisioning. While your sync is paused for the summer the retry is queued but nothing reaches Google or Entra until sync resumes (see Cloud sync is paused).

A class that Microsoft refused because your tenant has no Education licence (it asks for an "Education" property to be removed) has no Retry button: Microsoft refuses again until an Office 365 or Microsoft 365 A1, A3 or A5 licence is active. Read about class Teams opens Class Teams with Assignments, which explains the licence and how to switch class Teams off.

Ignore (declutter without deleting)

Ignoring never deletes anything — it's a reversible state that hides a group from the active triage view while keeping the full history. Ignore and Un-ignore need Change sync, platform & API settings:

• Ignore these current errors — clears this batch; new instances still surface.
• Ignore this type going forward — "I know about this, stop showing it" — future instances are hidden too, until you un-ignore.

Ignored groups are counted ("N ignored causes hidden") and viewable again: on Sync status switch on Show ignored, and on Logs open Filters and set Ignored errors to Show ignored. An Un-ignore button then restores them. Every ignore/un-ignore is attributed in the logs and audit trail.

"Seen 47 times, last seen today"

A problem that can't be fixed on its own — a class that can't be created because it has no mentor, an account the provider keeps rejecting — used to fail identically every run, filling the logs with the same message hundreds of times. Now each such recurring failure is recorded once per affected user and problem, with a running count and a last seen time, so a group reads "Seen 47 times · Last seen 2 hours ago".

That's more useful than a wall of duplicates: the count tells you how persistent it is, and a recent last-seen tells you it's still happening — exactly what to act on. If you fix the cause, the count simply stops climbing and the last-seen goes stale (and a later successful sync marks the group since succeeded). A different error for the same user is still its own separate group — nothing is hidden or merged that shouldn't be.

Once every instance of a cause has since succeeded, the row leaves the live list and is folded away underneath as "N causes sorted themselves out" — good news, kept out of the way.

Everything that filters by date — the "last N days" window, the sort order, the warning dot on the school switcher, the dashboard error counts — goes by last seen, not by when the problem first appeared. That matters most for the errors you most want to know about: a failure repeating every night keeps one row whose original date recedes into the past, so going by that date would have made the most persistent problems the first to disappear from view.

"Held" — a mass change the sync refused to make

Occasionally a group will say the sync held something rather than failing it: a removal of group memberships, or a batch of account suspensions, that it declined to carry out. A held group removal reads MEMBERSHIP REMOVAL HOLD … (Google and Microsoft 365), carries the You can fix this badge, and its Fix button is See the paused changes on your Dashboard.

This is a safety net, not a bug. If a MIS feed arrives empty or half-imported, the correct-looking conclusion is "every pupil has left every group" — and acting on it would strip the school's groups in a single pass. So when a run's removals look like that rather than ordinary churn, the removals are skipped, the additions still go ahead, and the hold is logged with the numbers it saw.

What to do: check your last MIS import — the Last MIS import on the dashboard, and whether the leavers are real in your MIS — and any bulk action someone took in Realsmart (for example suspending many people at once).

• If the removals were a mistake, put the missing people or groups back in Realsmart. The pause ends by itself overnight once the numbers are back to normal.
• If the change was intended, the removals won't happen on their own — the pause doesn't run out. For Google groups, choose Let removals go ahead on the card on your Dashboard (see Realsmart paused some changes to keep your groups safe). For Microsoft 365 groups, contact Realsmart support.
• If suspensions were held, the row reads SUSPEND GUARD: refusing to suspend N member(s) — the school has no ACTIVE/PROTECTED members left, which is a wiped MIS feed, not a leaver batch. Nobody was suspended, and running the sync again is held the same way. If your school really has emptied its roll on purpose, contact Realsmart support — only we can release it.

Don't work around a pause by removing people in Google directly.

"Out of time" — a group change that wasn't sent yet

A row starting Out of time after … NOT attempted means that night's run ran out of time before it could send this group change. Nothing changed in Google: the person wasn't added or removed. They stay flagged and the change is tried again the next time the sync runs, normally the next night. The badge is Will retry and there's no Fix button. You don't need to do anything. Big nights — the start of a term, or a weekly full check of every group — produce more of these, and they clear over the following night or two. If the same person and group show it several nights running, contact Realsmart support.

"Abandoned after … attempts" — Google kept saying no

A row starting Abandoned after N attempt(s) — retry budget exhausted (…) means Google kept slowing down or refusing a change (usually a rate limit) until the sync gave up for that night. The reason Google gave is in the brackets. The person is flagged and the change is planned again at the next run, so it's a Will retry cause. If one person shows it night after night, contact Realsmart support with the row.

"Group address already in use" — Google won't create the group

If a group's email address already belongs to a user account, a second address on an account, or a personal Google account, Google refuses to create the group and refuses every add to it (Not Authorized to access this resource/api). It shows as You can fix this, and Fix reads Review group addresses. Either rename the account or rename the group — see Group addresses in use. Separately, a group whose name is the same as someone's username (a user with that username already exists) shows Find the clashing user account.

"Inconclusive" — a check that couldn't reach a verdict

Inconclusive is not a failure. It means an automated check ran but didn't have what it needed to judge — usually a comparison with nothing valid to compare against yet. Nothing is broken, and nothing was changed.

It's reported separately from errors deliberately. A check that reports "all fine" when it actually learned nothing is worse than one that admits it, so these are surfaced honestly rather than rounded up into a green tick or down into a red error. No action is needed from you; if a check stays inconclusive for days, raise it. The one you're most likely to meet reads MASS-REMOVAL BACKSTOP NOT IN EFFECT — your sync ran normally, only its safety check couldn't be made that night; see The nightly Google group sync.

From the dashboard

The Sync activity bars on the Dashboard and Sync pages show what applied (green) with what didn't stacked on top (gold), and are clickable — a click opens the Logs page pre-filtered to exactly that day's failures, with a dismissible date chip. See The Dashboard and Sync centre for the Dashboard's version.

Result

Errors stop being a wall of red: the pages lead with what worked, each cause is one line that tells you whether to act, wait, or leave it to Realsmart — and gives you the one-click way to do it.