Summary
How to sync Google Calendar depends on which job is actually being asked for. It can mean the same Google account showing on a phone, another calendar overlaid on this screen through a share, a subscribe, a Secret address, or Add another account, or hours that must exist as busy-block copies on another calendar people book. The first two are native — if that was the whole job, they can stop here. If another account, Outlook, iCloud, or a booking page must see the time as taken on its own calendar, overlay cannot write that. That is the job Keeper.sh is for: connect the calendars, and copies land on the calendar that stays empty.
For the reader who has not picked a job yet, the forks are short. First time adding Google to this iPhone: how to add Google Calendar to iPhone, then stop. Google already listed on the iPhone and events missing or late: Google Calendar not syncing with iPhone. Two Google accounts that need busy-block copies between them: sync Google Calendars between two accounts. Merge or combine into one calendar is a different job than busy-block copies. Google hours onto Outlook: sync Google Calendar with Outlook, or to overlay Google into Outlook as a view, add Google Calendar to Outlook. Sharing with a person: how to share Google Calendar. Google onto signed-in iCloud: sync Google Calendar with iCloud.
The weakest link in every google calendar sync setup that spans two accounts: device sync, Add another account, share, Subscribe, From URL, and Secret address only change what this signed-in view shows. Import & Export is a snapshot Google says will not stay in sync. None of them write a busy block onto another calendar's primary calendar.
Keeper.sh exists for that write. It writes private copies — a placeholder title taken from the source calendar name — onto the calendar that stays empty when colleagues or a booking page check availability. Signed-in iCloud is a valid source and destination, same as Google and Outlook. Copies in both directions are two mappings. And connecting copies nothing by itself; events only move once they are sent.
The native paths below are wins when this-screen visibility was the whole job. Share, subscribe, and import fail the copy job for reasons Google documents itself. Then the numbered Keeper.sh setup.
Same Google account on this phone is device sync
The first job is the simplest, and it is already done by the phone. Signing the same Google account into the device shows that account's calendars there. Google's own Android walkthrough is blunt about it: "When you sync your calendar on your mobile device, the same events will show up when you use Google Calendar on your computer" (Sync Calendar with a phone or tablet — Android, checked 4 Sep 2026). Download the Google Calendar app, sign in, and "when you open the app, all of your events will be synced with your computer."
On an iPhone, Calendar.app does the same job. Per Google (Add Google Calendar events to Apple Calendar — iPhone & iPad, checked 4 Sep 2026): "On your iPhone or iPad, open your device settings," then "Scroll and tap Calendar. Tap Accounts → Add account → Google." After sign-in, "emails, contacts, and calendar events will now sync directly with your Google Account," and for an account that is already listed, "tap the account and turn on Calendars." That full walkthrough lives at how to add Google Calendar to iPhone — if this is the first add, go there and stop. If Google is already listed and events are missing or late, that is a different fix: Google Calendar not syncing with iPhone.
On a Mac, open Apple Calendar and add Google under Accounts (Add Google Calendar events to Apple Calendar — Computer, checked 4 Sep 2026). The syncselect page ticks which calendars inside this Google account appear in Calendar.app — it changes this device's view of this account; it does not write anything onto another account.
The verdict: if the same Google account on this phone or Mac was the whole job, device sync is native and they can stop. If hours must exist as busy blocks on a different calendar people book, device sync is the wrong tool.
Share, Subscribe, From URL, Secret address, and Add another account are overlay
The second job sounds like sync but is really "let me see both calendars on one screen." Here is the setup that exposes it: a meeting accepted on Google sits on the Google calendar. A colleague, a Find-a-time check, or a booking page looking at a second Google account, Outlook, or signed-in iCloud still sees that hour free. Every path in this section only stacks a view on top of this signed-in screen.
Add another account in the Google Calendar app shows a second Google account next to the first. Google: "In Google Calendar, you can add more than one account" — "At the top right, tap your Profile photo → Add another account" (Add another account to Google Calendar, checked 4 Sep 2026). Both calendars are now visible in one app. That is overlay, not copies.
Share grants someone a view of this calendar. Google's permission table runs from "See only free/busy (hide details)" up to "Make changes and manage sharing" (Share your calendar, checked 4 Sep 2026) — a permission on this calendar, not events written onto the other account's primary. Sharing with a named person is its own job: how to share Google Calendar.
Subscribe stacks the other calendar under "Other calendars." Google notes it must be done from a computer browser — "You can't subscribe to a calendar in the Google Calendar app for Android, iPhone, or iPad" — and "you can only add a calendar with a link if the other person's calendar is public" (Subscribe to someone else's calendar, checked 4 Sep 2026). The path is Other calendars → Add other calendars → "Subscribe to calendar" or "From URL."
The Secret address in iCal format is the same idea aimed at other apps: "The Secret Address lets you view your calendar in other applications, like Outlook or Apple Calendar," and "you should not give your Secret Address to other people" (Sync your calendar with computer programs, checked 4 Sep 2026). A pasted Secret address or ICS link is pull-only and never a destination. Google publishes no interval for how often a URL-added calendar is re-read, so any page quoting one is guessing. If Outlook only needs to display Google, that view is add Google Calendar to Outlook; if Outlook needs to hold the busy blocks, that is sync Google Calendar with Outlook.
The verdict: if both-visible was the whole job, overlay wins and they can stop. None of these write a copy onto the other account's primary calendar — which is exactly the copy job the next section solves.
Import & Export is a snapshot
Settings → Import & Export uploads a file once. Google's own words settle what it is: "You can transfer your events from a different calendar application or Google Account to Google Calendar," but "imported events don't stay in sync between your 2 accounts. If you want your calendars to sync, share your calendar with the other account" (Import events to Google Calendar, checked 4 Sep 2026). "By default, events are imported into your primary calendar," and guests and conference data do not come along.
So Import & Export is a one-time snapshot. It never updates itself, it never becomes a live copy, and new hours added to the source after the file was saved never reach the destination. Even Google's suggested "sync" here is share — which the previous section showed is still overlay.
Put Google hours on another calendar with Keeper.sh
The job that remains: hours on this Google calendar must exist as busy-block copies on another calendar people actually book — a second Google account, Outlook, or signed-in iCloud. That write is what overlay, share, subscribe, and import all fail to do. Keeper.sh does it in five steps.
- Sign in to Keeper.sh and connect the Google account on Google's own permission screen — Keeper.sh never sees the password. Connect the destination account the same way: a second Google account, Outlook, or signed-in iCloud. Click-by-click is in /docs/accounts-and-calendars. Connecting copies nothing by itself; events only move once they are sent. Free is 2 accounts and 3 connections, and one sign-in is one account however many calendars sit inside it.
- Open the source calendar — the Google calendar that is full. Under Send Events to Calendars, tick the destination, the calendar people actually book. One tick is one mapping. Per /docs/sending-events-to-another-calendar: "Each calendar you tick becomes one connection. Events are copied into it, one way, and the copies are kept corrected as the originals change."
- If the other direction is needed too, open the destination calendar's page and tick the Google source. Copies in both directions are two mappings — one from each calendar's page. Free's 2 accounts and 3 connections still fit a pair plus one extra. A pasted share, ICS, or subscribe link is not a destination; if a URL was connected instead of a sign-in, events can be sent from it, not into it.
- Leave the privacy defaults on. A copied event shows a placeholder title — the name of the calendar it came from — with no description and no location, on every plan. Those toggles are Pro, and guest lists are never copied. Details: /docs/what-a-copied-event-shows.
- Confirm on the destination: a real event, named after the source calendar, with no notes, no location, and no guest list. Then wait for the next write. On Pro, Google Calendar and Outlook notify Keeper.sh the moment an event changes, so the copy lands within seconds. We do not notify Google or Outlook. iCloud, Fastmail, and other CalDAV calendars are checked on a timer on either plan, because Apple publishes no way for a calendar tool to be told an event changed; the timer applies to iCloud on both plans.
For a signed-in iCloud destination, make an app-specific password in Apple account settings first; Keeper.sh's docs cover it under /docs/accounts-and-calendars. If nothing arrives, see /guides/event-has-not-arrived; two of something, /guides/same-event-appears-twice; a feed that stopped refreshing, /guides/subscribed-calendar-out-of-date. Unticking a calendar stops new copies while events already copied stay put. One-line recipes if they fit the setup: /recipes/sync-work-and-personal-calendars and /recipes/keep-personal-details-out-of-work.
Specific pair pages if that is the whole job: two Google accounts → /blog/sync-google-calendars-between-two-accounts; Google → Outlook → /blog/sync-google-calendar-with-outlook; Google → iCloud → /blog/sync-google-calendar-with-icloud; Apple hours onto Google → /blog/how-to-sync-apple-calendar-to-google-calendar.
Sources are read every minute on every plan; free destinations write every 30 minutes. Pro is $5 a month, or $45 a year paid annually — details in /docs/plans-and-limits.
Why a Keeper.sh copy instead of a share or a device sync
Device sync did its job: the same Google account now shows on the phone, and if that was the whole job, there is nothing left to fix. The remaining problem was never this device. It is the other calendar — the one colleagues check, the one a booking page reads — staying empty while the meeting sits on Google. A Keeper.sh connection writes a private copy onto that calendar, so the hour shows as taken where people actually look.
Share, Subscribe, From URL, and Secret address only stacked a view on one screen. A Keeper.sh copy is a real event on the destination: placeholder title, description and location hidden, no guest list — visibility as a busy block without leaking what the meeting is. And where Import & Export was a snapshot Google itself says will not stay in sync, copies keep correcting as the originals change: on Pro, Google Calendar and Outlook notify Keeper.sh the moment an event changes, while iCloud stays on the timer because Apple publishes no way to be told. That is the whole difference between a view and a copy — and it is the only part of this job that needs a tool at all.