Combining multiple calendars not working: what to check, in order

A work Google account, a personal iCloud calendar, a client's Outlook calendar shared by link. On paper they all land in one view. In practice the Monday standup shows up twice, the finance team's shared calendar is missing, and a meeting moved this morning still sits in its old slot after lunch. Removing and re-adding accounts rarely helps, because the problem is usually not one broken account. It is the way several feeds are stacked on top of each other.

This guide treats a combined calendar as what it really is: a stack of separate feeds, each with its own refresh clock and its own rules about who can write to it. Work through the checks in the order below and the fault narrows to one place.

Sort the failure into one of five kinds

Before changing any setting, name the failure. Pick the one that hurts most, even if more than one applies. Chasing two at once is how a fix for one hides the cause of the other.

• Too many. The same event appears two or three times.
• Missing. A whole calendar, or a certain kind of event, never appears.
• Stale. A change made at the source has not reached the combined view.
• Shifted. Times are off by an hour or more, or all-day events spill into the next day.
• Bouncing. An edit made in the combined view reverts later, or cannot be saved at all.

Each kind points to a different layer. Too many points to overlapping feeds. Missing points to selection and permission. Stale points to refresh intervals. Shifted points to how the time was written in the event data. Bouncing points to the direction in which writes are allowed to travel.

Write down two or three concrete examples, with the date, the event name and what looks wrong. "Tuesday 10:00 design review, two copies, one pale" is enough. Those same events become the test cases when checking whether a change worked.

Map how each calendar reaches the screen

The single most useful step is a feed map. List every calendar visible in the combined view and note how it arrives. The same Google calendar behaves very differently depending on the route.

Route	How it updates	Can the combined view write to it
Signed in as that account	Follows the account's refresh setting	Yes, within the account's rights
Shared from another account	Reflects changes made by the owner	Depends on the permission granted
Subscribed by URL (.ics)	Only when the subscribing service polls	No
Imported from a file	Never; it is a snapshot	The copy only, never the original
Busy block placed by a sync service	On the service's own schedule	Edits to the block do not reach the source

On a Mac, the sidebar in Calendar groups calendars under the account that holds them. A calendar subscribed by URL is stored either in iCloud or On My Mac, chosen at the moment of subscribing, so it sits under one of those headings rather than under the Google account. A calendar subscribed inside Google appears under "Other calendars" when Google Calendar is opened in a browser. Comparing both lists often reveals the same .ics feed subscribed twice, once on each side.

Any calendar whose route cannot be identified deserves attention first. Leftovers from an earlier experiment, an import from last year or a trial of a sync service, are among the most common causes of every symptom below.

Too many: look for two routes to the same calendar

Duplicates almost always mean one calendar is arriving by two routes. Three patterns account for most cases.

• Account A shares its calendar with account B, and the calendar app is signed in to both A and B.
• A sync service copies busy blocks into a second calendar, and both the originals and the blocks are visible.
• An old import still holds static copies of events that now also arrive live through sharing.

Google's help page on importing is explicit that imported events do not stay in sync between two accounts. If someone imported a file early on and later set up sharing, the snapshot and the live version will sit side by side indefinitely.

To confirm, open both copies and check which calendar each belongs to. Different calendars mean an overlap of routes, not a display bug. The fix is to hide one of the two calendars from the view. Deleting one of the events is the wrong move, because a deletion can travel back to the owner of a shared calendar or to the organizer of a meeting.

One case looks like a duplicate but is not. A meeting invitation exists once on the organizer's calendar and once on each attendee's own calendar, where it carries that attendee's response. If both calendars are visible, both entries are legitimate. Keep whichever answers the question being asked: the attendee copy shows the response, the organizer copy shows the full meeting.

Missing: selection, permission, or a limit

When something never appears, there are only three places to look.

Selection. Apple devices using a Google account do not always pull down calendars shared from other people. Google's help directs users to the Calendar sync page on a computer, where each shared calendar can be ticked for syncing.

Permission. Google offers several sharing levels, from "See only free/busy (hide details)" up to "Make changes and manage sharing". A calendar shared at the free/busy level shows untitled blocks in some apps and nothing at all in others. Microsoft's list of known issues for Google accounts added to Outlook states that a calendar shared with Free & Busy permissions does not work.

Limits and administrators. The same Microsoft page notes a limit of 20 calendars shared with the user. For work and school accounts, Google's help says the administrator decides whether a calendar can be shared at all. If every personal setting looks right and the calendar is still absent, an organization policy blocking external sharing is the likely reason. A quick way to tell is to ask a colleague in the same organization whether the same calendar reaches them.

Stale: every feed runs on its own clock

Stale events cluster around calendars subscribed by URL. A subscription is a pull. Nothing is pushed; the subscribing service fetches the file when its own timer says so.

This update can take more than 24 hours, although updates should happen approximately every 6 hours. Source: support.microsoft.com

That note refers to Outlook on the web. For Outlook.com, the same page gives roughly every 3 hours, again with the caveat that it can exceed 24 hours. Calendar on the Mac lets the user choose an auto-refresh interval in the Get Info window of a subscribed calendar. Google Calendar offers no setting for how often it polls a subscribed URL.

Delays also stack. If a client publishes an .ics file, Google subscribes to it, and a desktop app then reads that Google calendar, the event has to pass two separate timers before it appears. Shortening the last timer does nothing for the first. For calendars where same-day changes matter, the better question is whether the owner can share the calendar directly instead of publishing a link.

Measuring the actual delay takes a few minutes of effort and removes the guesswork. Create a dummy event at the source with the current time in its title, then note when it appears at each stage of the chain: the first subscribing service, then the app on the Mac. If it reaches Google within the hour but the desktop app lags far behind, the problem is the last hop. If it has not reached Google by the end of the day, no change on the Mac will help. Delete the dummy event at the source afterwards, and check again later that the deletion also travelled down the chain, since removals follow the same timers as additions.

Imported calendars are a separate case: they never refresh. Google's help adds that repeating events imported from a .csv file may show up as a series of one-time events, which means a later change to the series cannot be applied in one step.

Shifted: check how the time was written

An event that is off by a fixed number of hours usually has a time zone problem inside the event data itself, not in the app. The iCalendar standard allows a time to be written with no time zone attached.

DATE-TIME values of this type are said to be "floating" and are not bound to any time zone in particular. Source: rfc-editor.org

A floating time is read in whatever time zone the viewing device is set to. That produces a few recognizable patterns:

• A feed published by someone in another country shows their local clock numbers in the viewer's time zone.
• A travelling laptop changes time zone and only some events move with it.
• An all-day event passes through an account set to a different zone and becomes an evening-to-evening event.

Open the shifted event at its source. If the source shows the correct time and an explicit time zone, the combined view is misreading it, and the app's own settings are the place to look. Calendar on the Mac has a time zone support option under Settings, then Advanced, which shows the zone of each event. If the source event has no time zone, nothing on the viewing side can repair it. The publisher has to export the feed with zones included.

Bouncing: writes going the wrong way

An edit that reverts, or refuses to save, is a sign that the write is heading down a route that does not accept writes. Apple's guide states plainly that subscribed calendars cannot be edited. Changing an event from a subscription inside a combined view has no destination.

Busy blocks from sync services behave the same way from the other direction. The block is a separate event generated from the original. Dragging the block to a new time lasts until the next sync pass, which puts it back. The rule is simple: always edit the original event, never the copy.

A quieter mismatch appears when a Google account is added to Outlook. Microsoft's known issues list says events created in Outlook default to "Public" visibility regardless of the Google Calendar setting. Nothing bounces, but events created in the combined view end up with different visibility from events created at the source, which matters when that calendar is shared.

When everything stops at once

If a setup that worked yesterday goes silent across the board, check authentication before touching any calendar settings. iCloud is the usual suspect, because third-party apps and services connect to it with app-specific passwords. Apple's support page says that changing or resetting the main Apple Account password revokes all app-specific passwords automatically, and each app then needs a new one. An account can hold up to 25 of them, so labelling each with the app it belongs to saves guesswork the next time.

Work accounts can also stop without any change on the user's side, when an administrator withdraws approval for an outside app or tightens a policy. The app typically shows only a prompt to sign in again. If colleagues see the same failure on the same day, the cause sits with the organization, not the device.

What to change first

Draw the feed map before anything else, then run only the check that matches the symptom. Once duplicates and delays are gone, the next problem is usually the day itself, with back-to-back meetings that were invisible while they lived in separate calendars; the travel time guide covers planning the gaps between them. For a side-by-side view of how calendar apps handle accounts, sharing and subscriptions, see the comparison page, or read how Caltimate brings those calendars into one Mac view.