Google Calendar not syncing with Outlook on Mac: where it stops

A meeting moved in Google Calendar, Outlook on the Mac still shows the old time, and nothing in either app reports an error. That silence is the real problem. Calendar sync between Google and Outlook is not one connection. It is three or four separate paths stacked on top of each other, and each one fails in a way that looks identical from the outside.

The fastest way out is to stop trying fixes and identify which path is actually carrying the events. Once that is clear, most cases resolve in one setting change, and a few turn out to be working exactly as designed.

Three paths, one symptom

There are only a handful of ways a Google calendar reaches Outlook on a Mac, and they have very different properties.

The first is an account connection, where Outlook signs in to the Google account and syncs mail and calendar through Microsoft's service. Events move in both directions, and changes propagate without a fixed schedule.

The second is a subscription to a calendar URL. Google publishes a calendar as an address in iCal format, Outlook subscribes to that address and refreshes it periodically. This path is read-only by definition. An event edited on the Outlook side never reaches Google, because there is no channel back.

The third is invitation email. When a Google Calendar user invites someone whose calendar lives on a different service, the invitation and its updates arrive as email that the receiving calendar parses. Google's own documentation is explicit that these messages are required for event sync, and that they come from a fixed sender address.

While required for event sync, the emails can clutter your inbox. Source: support.google.com

The fourth path exists only on Windows. Google Workspace Sync for Microsoft Outlook is distributed as an EXE installer, and its setup instructions reference Windows versions and the Start menu. On a Mac it is simply not available, which matters because a large share of the troubleshooting advice written for Outlook and Google Calendar assumes it is running.

Knowing which of these four is in play tells you immediately whether two-way sync was ever possible. If the calendar arrived through a URL subscription, edits made in Outlook were never going to appear in Google Calendar, and no setting will change that.

Path	Direction	Typical failure
Account connection	Both ways	Authentication expires silently
Calendar URL subscription	Read-only into Outlook	Edits in Outlook vanish, refresh lags
Invitation email	Per event, both ways	Filters or rules delete the sync messages
Windows sync tool	Both ways	Not available on macOS

When the account connection is the one that stopped

An account connection is the only path that gives genuine two-way behavior, and it is also the one that fails most quietly. Authentication tokens expire, two-step verification changes, and the app keeps showing the last data it received rather than an error.

Two checks separate a dead connection from a slow one. First, open the same calendar in a browser at calendar.google.com. If the change is visible there, the event left the device that created it and the problem sits downstream. If it is not visible there, the event was written to a calendar that is not part of that Google account, which happens constantly on machines signed in to both a work and a personal account.

Second, check whether anything at all has arrived recently. A connection that is slow moves events within minutes. A connection that is broken stops at a specific moment and never advances, and the last synced event usually has a timestamp that lines up with a password change or a security prompt that was dismissed.

One limit is worth knowing before spending time on this. Google states that calendar apps sync past events up to one year back, and that older events are not synced at all. A history that looks truncated in Outlook is not necessarily a broken connection.

It helps to write down three facts before changing anything: the exact time of the last event that did arrive, the account the event was created under, and whether the change was made on the web or in a desktop client. Those three together usually point at the layer without any further testing. A last-synced timestamp that stops at a round hour points at an expired credential. A timestamp that keeps moving while one specific calendar stays frozen points at scope rather than authentication, which is a different fix entirely. And a change made in a desktop client that never reaches the web points in the opposite direction from everything described so far, which narrows the candidates down to one.

Read-only subscriptions and the four hour rule

A subscription to a published calendar address is the most common setup on a Mac, because it needs no admin involvement and no password sharing. It also causes the largest number of complaints, because it behaves nothing like an account connection.

The address itself has a precondition. Google's documentation notes that the public address in iCal format only works if the calendar is public. Copying that address out of a private calendar produces a subscription that authenticates but returns nothing, which reads as a sync failure.

Sharing changes are also not instant.

This change usually only takes a few minutes, but may take up to 4 hours to take effect. Source: support.google.com

That window explains a whole category of reports. Someone makes a calendar public, subscribes from Outlook, sees nothing, concludes the setup is wrong, and starts over. The original attempt was correct and simply had not propagated yet.

The reverse direction has its own limit. Google Calendar cannot subscribe to calendars that are not from Google, so an Exchange or iCloud calendar cannot be pulled in the same way. Where such a bridge does exist, propagation is measured in hours rather than minutes, and there is no supported setting that speeds it up.

Volume matters too. Subscribing to more than 400 calendars can cause performance problems when browsing calendars, according to Google's documentation. Organizations that created a calendar per project or per room reach that number faster than expected, and the resulting sluggishness gets misread as a sync delay.

Invitation email is a sync channel, not noise

The path that breaks most often for reasons nobody suspects is invitation email. Google sends calendar sync messages from a dedicated address, and any inbox rule that files or deletes them removes the mechanism that keeps a third-party calendar accurate.

The documented approach is to filter on the sender in the message header and route the messages somewhere out of sight rather than discard the channel. Outlook inbox rules can do this. What fails is the intuitive fix, which is to delete anything that looks like a duplicate invitation.

There is also a time boundary here. Invitation emails carry correct information for recurring events up to 30 days in the past. For an older occurrence of a repeating meeting, resending the invitation does not bring the two calendars into agreement, and the practical answer is to recreate the series rather than keep repairing it.

Differences that are not failures

Some mismatches between Outlook and Google Calendar are documented behavior. Recognizing them early saves hours.

Monthly recurrence on the 31st is the clearest example. Google's comparison of the two products states that an event recurring on the 31st appears on the last day of every month in Outlook, including months shorter than 31 days, while Google Calendar shows it only in months that have 31 days. Two calendars will legitimately disagree on how many occurrences exist.

Forwarded invitations behave differently as well. If an attendee forwards a Google Calendar meeting from Outlook, the person who receives the forwarded invite is not added to the event even after accepting it in Outlook. The organizer sees an attendee list that does not match what the forwarding chain suggests.

Free and busy lookups across the two systems are conditional rather than automatic. Seeing availability for people on Microsoft Exchange requires a connector that an administrator enables, so an empty availability grid is often a permissions question rather than a sync question.

A few capabilities simply do not cross over. Creating a new Google calendar is only possible in a browser, and Google lists event email notifications, creating new Google calendars, and room booking as features unavailable when Google Calendar is reached through Apple Calendar. Attempting these from the desktop client produces no error and no result.

The Apple Calendar option on a Mac

Because the Windows sync tool is unavailable, many Mac setups end up routing Google Calendar through Apple Calendar instead of Outlook, either as the main calendar or as a bridge. Two settings decide whether that works.

Refresh frequency is chosen per account in Apple Calendar's account settings. A long interval produces exactly the symptom this article started with: events sync correctly, but the local copy is stale for as long as the interval lasts.

Scope is the second setting, and it surprises people. Calendars under "My calendars" plus Birthdays sync automatically. Calendars shared by other people, which land under "Other calendars", do not. Adding them requires visiting the calendar sync page in a browser and enabling each one. A separate trap is delegation: Google's documentation states that turning the delegation tool off is what makes Google Calendar sync work when delegation was previously used. That setting lives under the account's delegation panel, and it has to be cleared for every calendar listed there, not just the one that appears broken.

Routing through Apple Calendar changes what is possible rather than only how fast it is. Event email notifications, creating new Google calendars, and room booking are all listed as unavailable on that path. A team that books meeting rooms from the desktop will hit the third one immediately, and the failure is silent, so it tends to be discovered by a colleague standing outside an unbooked room. Where room booking matters, the browser stays part of the workflow no matter which desktop client sits in front of it.

Anyone comparing desktop options on macOS will find the tradeoffs laid out in Compared with other calendars, and the range of what a native client can and cannot do in Features.

What to change first

Start by naming the path. Open calendar.google.com, confirm the event exists there, then determine whether Outlook holds an account connection or a read-only subscription, because that single fact decides whether two-way sync was ever available. If the calendar arrived as a URL, stop trying to fix the direction and move the editing back to Google Calendar.

After the path is correct, the remaining gap is usually the schedule itself rather than the plumbing. Travel between two back-to-back meetings never appears on either calendar, so a working sync still produces a day that falls apart. Making that time visible is covered in Travel time, and a Mac client built around fast entry is described at Caltimate.