Googleカレンダーの同期 not working: what to check, in order

When a Google calendar stops syncing properly, the usual response is to start changing settings. That approach eventually produces a working calendar and no idea which change was responsible, which means the next occurrence starts from zero again.

There are not many possible causes. What matters is the sequence, because the checks are not equally expensive and they are not equally likely. The ones below are ordered so that the cheap, high probability checks come first, and removing the account to add it again comes last. That step is at the bottom for a reason: it helps in a narrow set of circumstances, and when it does not help it leaves nothing behind to learn from.

Name the symptom before touching anything

What gets reported as a sync problem is really four separate symptoms, and saying which one out loud eliminates most of the search space.

Nothing from the account appears at all. The account row exists in the sidebar but is empty, or the row is missing entirely. This points at the connection or the authorisation, and individual calendar settings are irrelevant for now.

Some calendars are missing while others are fine. Personal calendars arrive, shared ones do not. That is not a connection fault. It is a question of which calendars were selected to come down.

Events arrive but arrive late. Something entered on another device shows up after a wait. This is usually not a fault at all. It is the configured fetch interval behaving exactly as configured.

Events are visible but cannot be changed. Edits fail to save, or an event vanishes moments after being created. Either the route is read only, or the permission on that calendar stops at viewing.

Step one: whole account, or one calendar

Establish the scope before anything else. If other calendars on the same account display correctly, the connection is alive and authorisation is working, which removes two of the most time consuming suspects immediately.

If the entire account is blank, examining individual calendar settings is wasted effort. The problem is upstream of them.

The quickest way to establish scope is to put the web interface next to the local sidebar and compare. Only the calendars present on the web and absent locally are worth investigating. Anything missing from the web as well was never on the account, and no local setting will produce it.

Step two: delegation left switched on

This one is easy to miss, hard to guess, and produces a severe symptom. Apple Calendar includes a delegation feature for working with calendars belonging to other people, and a leftover configuration there blocks ordinary syncing. Google's guidance states the remedy plainly.

Apple カレンダーの [委任] ツールを使用して同期していた場合は、このツールをオフにすると Google カレンダーとの同期が動作するようになります。 出典: support.google.com

The setting lives in the calendar app's account preferences, on the delegation tab. Turning off everything listed there is the fix. Anyone who once set up access to a colleague's calendar, or who migrated settings across from an older Mac, has a meaningful chance of carrying this forward without knowing it.

The symptom it produces is the first one on the list: nothing appears. Since the credentials are valid and the account looks connected, the natural reaction is to suspect authorisation and sign in repeatedly, which is a long detour. Checking delegation takes under a minute and either resolves the problem completely or eliminates it.

Step three: whether macOS is letting the app in

Both Google and the app can be configured correctly while macOS quietly blocks the connection between them. The first time an app reaches for calendar data, the system asks for permission. Dismiss that prompt, or decline it while busy with something else, and the app reads nothing from then on, without an error message.

The place to look is System Settings, under Privacy and Security, in the Calendars entry. The app should be listed with its switch enabled.

On macOS 14 and later there is an extra level of detail. Opening the options next to an app in that list offers a choice between full access to calendars and add only access. An app granted add only can write events but cannot read existing ones, which produces a distinctive picture: events created locally are the only ones on screen and everything else is absent. No amount of adjustment on the Google side changes that, so a screen matching this description should send you here first.

Step four: whether the authorisation is still valid

If nothing above applies, the connection itself is next. A sign in lapses when a password changes, when the device used for two step verification is replaced, or when an administrator alters the conditions for third party access. It does not always fail loudly. Often it just stops.

Following outdated instructions produces the same appearance. Typing a password directly into an app no longer works: for Google Workspace accounts that route closed on 14 March 2025. A setup screen asking for a server name and a password is an obsolete path, and the fix is to use the one that opens a Google sign in page instead.

There is a second place to confirm this. The security section of a Google account lists connections to third party apps. An app that is missing from that list is not connected, whatever the Mac appears to show.

When only a work account misbehaves, the cause is probably not local. Add a personal account to the same Mac using the same steps. If that one works, the local configuration and permissions are correct and the block sits on the organisation's side, where repeating the setup accomplishes nothing and asking the administrator accomplishes everything.

Step five: record the symptom before continuing

Past this point, measurement replaces guessing. Without a record, there is no way to distinguish a fix from a refresh interval that happened to come around.

Three values are enough: the time an event was created, the time it appeared on the other device, and whether anything else was touched in between. A handful of those settles whether events are late or absent. 30 minutes with no appearance means absent, not late. Appearing at roughly the configured interval means the behaviour is correct and the interval is the thing to change.

Direction matters as much as timing. Local changes reaching another device faster than the reverse is how a pull based mechanism is supposed to behave. Nothing moving in either direction points at the connection. Movement in one direction only points at permissions or at which calendar new events are being saved to.

Where new events are being saved

One cause deserves its own step because it imitates a sync failure so convincingly. Every calendar app has a default calendar for new events, and adding a Google account does not necessarily change it. If that default still points at a local or iCloud calendar, events typed on the Mac are saved somewhere that Google never sees.

The resulting picture looks exactly like one way sync. Events entered elsewhere arrive on the Mac. Events entered on the Mac never leave it. Nothing is broken and no permission is wrong: the events are sitting on a different calendar that happens to look identical in the grid.

The check is to open one of the missing events and read which calendar it belongs to. If the answer is a local calendar, the default setting is the cause. Correcting the default fixes everything created from that point on, and does nothing for the events already saved in the wrong place. Those have to be opened individually and reassigned, which is worth doing before the list grows.

The same confusion appears in reverse on calendars shared by other people. A calendar shared at a view only level accepts a new event in the interface and then discards it, sometimes after a visible pause. That is the sharing permission, not the sync mechanism, and no local setting will change it.

How long each step should take

Knowing the expected cost of each check stops the sequence from stalling on the wrong one.

Establishing scope is a matter of looking at two screens side by side, so under a minute. Delegation is one preferences tab. The macOS permission is one settings pane. Together these three account for the majority of cases where nothing appears at all, and they finish in about 3 minutes.

Authorisation takes longer because it may involve signing in again and checking the connections list on the Google account, perhaps 5 minutes. The default calendar check is quick but requires that at least one missing event can be found.

Recording timings is the only step measured in hours rather than minutes, since it needs events created and then waited on. That is precisely why it sits after everything cheaper. Reaching it means the obvious causes have been eliminated and the question has narrowed to whether events are late or absent, which is a question only measurement can answer.

Anyone who has spent longer than 10 minutes without working through this list in order has almost certainly been re entering credentials rather than checking the settings that produce the same symptom for free.

Symptoms that settings cannot fix

Some complaints survive every check because they describe absences rather than faults. Adding a Google account to Apple Calendar does not carry three Google Calendar features: email notifications for events, creating a new Google calendar, and room booking.

A meaningful share of reports about missing rooms or missing email reminders land exactly here. There is nothing to repair. Routing those specific actions to the web interface is the practical response.

Subscribed calendars behave similarly. A calendar added by pasting a private address cannot be edited locally. An event that snaps back to its old time, or reappears after deletion, is the mechanism working as designed rather than breaking. Restoring write access means connecting the account instead.

Confirm the fix before walking away

Once a cause is found, verify it. Skipping verification means that a second, unrelated cause goes undetected and the whole sequence gets repeated later.

Test in both directions. Create one event locally and watch for it elsewhere, then create one elsewhere and watch for it locally. Writing and reading are separate paths, and one working says nothing about the other.

Give the test event a name that is easy to find and place it on a future date, so that a forgotten test does not blend into real commitments. Then delete it and confirm the deletion propagates too, because deletion sometimes travels differently from creation.

Where several calendars are involved, test one that was already healthy as well as the one just repaired. Configuration changes occasionally alter behaviour elsewhere. With all 4 paths confirmed, sync itself is sound.

What to change first

Open the delegation tab and the macOS Calendars permission before touching the account, since those two take a minute between them and cover the symptoms that look most alarming. What remains once sync behaves is not a sync problem: it is how quickly events get recorded and how a packed day reads, which is what Caltimate is built around. Entry is covered in entering events and the gaps between meetings in travel time.