Google Calendar account sync: what actually crosses over

Adding a Google account to a desktop calendar takes about thirty seconds and produces a result that looks complete. Events appear, the sidebar fills up, and the setup feels finished. A week later something is missing: a shared team calendar that exists in the browser and not on the Mac, an event reminder that used to arrive by email and no longer does, or a colleague's calendar that was subscribed to months ago and never made the trip.

None of those are bugs. They follow from a fact that the setup screen never mentions. Signing in connects an account, but the account is not the unit that syncs. Individual calendars are, and they are governed by a list that lives somewhere else entirely.

The account is a container, not the thing being synced

A Google account holds several kinds of calendar and they are not treated alike. There are the calendars created in that account, which appear under My Calendars in the browser. There is the automatic birthdays calendar. There are calendars belonging to other people that have been shared, which land under Other Calendars. There are subscriptions to public feeds, holiday calendars, and in a work account there are meeting rooms and resources.

When a desktop client signs in, it does not fetch all of that. Google's own instructions state which ones come across without being asked: any calendar under My Calendars, plus Birthdays. Everything else in the account has to be selected explicitly.

This is why the same account looks different in two places. The browser reads directly from the account and shows everything. A desktop client reads through a sync list that defaults to a subset. The gap between them is not a delay and will not resolve on its own, no matter how many times the calendar is refreshed.

The reason for the design is bandwidth rather than obstruction. A work account can be subscribed to dozens of team and room calendars, and pulling all of them onto every device on every refresh would be wasteful for calendars nobody looks at. The trade off is that the default is quiet, and a missing calendar looks exactly like a broken sync.

The list that decides what crosses over

The selection lives on a Google page rather than in the desktop application, which is why nobody finds it by clicking around in the app.

Open Google Calendar in a browser and go to the calendar sync settings, reachable from Google's own help page for adding Google Calendar events to Apple Calendar. The page shows every calendar in the account with a checkbox. Tick the ones needed, save, then refresh the calendar on the Mac.

Three things about this page are worth knowing before using it.

It is per account, not per device. Ticking a calendar there makes it available to every client connected to that account, which is convenient when the same calendar is wanted on a Mac and an iPhone, and a nuisance when it is wanted on only one of them. Device level control has to happen afterwards, in the client, by hiding the calendar rather than unsyncing it.

It only lists calendars the account can already see. A colleague's calendar that was never shared will not appear there, because the problem is a permission on their side rather than a setting on this one.

And the change is not instant. After saving, the client needs a refresh cycle to notice. Waiting one interval before concluding that nothing happened saves a round of unnecessary troubleshooting.

Three Google features that do not survive the trip

Some things are absent from a desktop client not because they failed to sync but because they have no equivalent outside the browser. Google lists them plainly:

Google Calendar features that don't work on Apple Calendar: Email notifications for events, Create new Google calendars, Room Scheduler Source: support.google.com

Each one has a practical consequence.

Email notifications are the one that catches people out, because they are configured per calendar in the browser and simply stop being honoured for a client that has no way to request them. An event set to notify by email one day ahead still notifies, since the notification is generated by Google, but the notification settings edited on the Mac apply only to the alerts the Mac itself produces. Two independent notification systems ends up either duplicating alerts or silencing them, and the fix is to decide which side owns notifications and turn the other side down.

Creating calendars is a hard restriction rather than a client limitation. Google states that new calendars can only be created from a browser, and that they appear in apps afterwards. A desktop client can create events in existing calendars all day and cannot create the container.

Room booking belongs to the same category. Meeting rooms in a work account are resources rather than calendars, and reserving one generally means going back to the browser or to whatever internal booking tool the organisation uses.

Task	Works in a desktop client	Where it has to be done
Create, edit, delete events	Yes	Anywhere
Add a shared calendar to the sidebar	Only if selected first	Google sync settings page
Create a new calendar	No	Browser
Email notifications for events	No	Browser, per calendar
Book a meeting room	No	Browser or internal tool

Refresh intervals, and the events that arrive late

An event created on a phone and still missing from the Mac twenty minutes later is usually not a sync failure. It is a schedule.

Apple's Calendar app fetches on an interval set per account, under the Accounts tab, in a control labelled Refresh Calendars. The options run from every minute to once a day, with a manual option at the end. An account left on the hourly setting will behave exactly as described: correct, and an hour behind.

Writes generally go the other way faster than reads come back, which produces the asymmetry people describe as one way syncing. An event created on the Mac appears on the phone quickly because the Mac pushes it on save. An event created on the phone waits for the Mac's next fetch. Nothing is broken in either direction, and shortening the interval fixes the perception.

There is a cost to setting every account to one minute. Each fetch is a network round trip per calendar, and on a laptop running several accounts with many calendars each, the aggregate is noticeable on battery. A reasonable compromise is a short interval on the account where events actually arrive from other people, and a long one on personal calendars that only ever change from this machine.

A second account changes where new events land

Most of the difficulty people describe as an account sync problem starts the moment a second account is added. Both accounts sync correctly. The trouble is that the calendar now has to decide, on every new event, which account it belongs to, and the default is set once and rarely revisited.

The default calendar is a per application setting rather than a property of either account. In Apple's Calendar it sits in settings under the general tab, as a single choice from a list of every calendar in every connected account. Whatever is chosen there receives every event created without an explicit calendar selected, including events created by Siri, by accepting an invitation that arrives outside an account, and by dragging a date out of another application.

The failure this produces is quiet. A personal event created during a working day lands on a work calendar that colleagues can see the title of. A work commitment lands on a personal calendar that nobody at work can see, so it does not appear in availability checks and gets double booked. Neither of these throws an error and neither is visible in the grid, because both events look correct where they are.

Two habits remove almost all of it. The first is choosing a default calendar deliberately and choosing the one where a mistake is least costly, which for most people is a personal calendar rather than a shared work one. The second is developing the reflex of glancing at the calendar field before saving, which takes a second and is the only reliable check.

Colour helps as a warning system rather than a fix. Setting every calendar in one account to a shade of one colour, and every calendar in the other to a shade of another, turns a misfiled event into something noticeable at a glance in week view. That is a display setting stored on the device, so it survives sync changes and has to be repeated on each machine. What each desktop client offers here differs, and the practical differences are set out in Compared with other calendars.

The delegation setting that blocks sync silently

One legacy setting produces a failure that looks like a broken account and is not.

Apple's Calendar has a Delegation tab, used historically to see calendars belonging to other people. Google's instructions are explicit that this route conflicts with the current one: if delegation was used previously, it has to be turned off for calendar sync to work. Every calendar in the delegation list needs to be unticked.

The symptom is a Google account that authenticates successfully, appears in the sidebar, and shows either nothing or a stale subset of events. Checking Calendar, then Accounts, then Delegation takes ten seconds and rules out a setting that no amount of removing and re-adding the account will clear, because the delegation entries survive the account being deleted and restored.

This matters most on machines that have been carried forward through several versions of macOS, or on accounts that were originally set up by an administrator. A clean install of a recent system will usually have an empty delegation list, and the check can be skipped.

Work and school accounts add a second layer above all of this, and it is not a setting anyone can reach from a Mac. An administrator can restrict which external applications may connect to an account at all, in which case sign in either fails outright or succeeds and returns nothing. The distinguishing symptom is that the same account works perfectly in a browser on the same machine, because the browser is the one client the policy always permits. Google's own guidance for organisations points at a separate tool for Outlook rather than suggesting a workaround, which is a fair indication that there is no client side fix. The only route is a request to whoever administers the account.

Where the phone and the desktop diverge

The same account can show a different set of calendars on a phone and on a laptop, and the reason is that two different mechanisms are in play.

Google's own application on a phone reads the account directly and has its own per device list of which calendars to display. A desktop client that connects through the standard calendar protocol reads through the sync selection page described earlier. The two lists are unrelated. Ticking a calendar in one has no effect on the other, which is why a calendar can be present on a phone, absent on a Mac, and correctly configured in both places at once.

This has a practical implication for troubleshooting. Comparing a phone against a Mac proves nothing about whether an account is syncing, because the two are not consulting the same list. The comparison that is worth making is between a browser and the client in question, since the browser shows the account's true contents. If the calendar is in the browser and not in the client, it is a selection issue. If it is missing from the browser too, it is a sharing or permission issue, and no amount of work on the client will produce it.

What to change first

Open the Google sync settings page in a browser and confirm that every calendar actually needed is ticked, because that single list explains most of what looks like a missing calendar. Then set the refresh interval on the account where other people create events to something short, and leave the rest long. If the remaining friction is how long it takes to get an event into the calendar rather than what the calendar shows, Caltimate is aimed at that half.