Calendly sync with Google Calendar: closing the double booking gap

A booking arrives for a slot that was already taken. The calendar showed the conflict the whole time, on the same screen, in a different colour. Nothing was broken and nothing was offline. The booking service simply was not looking at the calendar where the conflicting event lived.

Connecting Calendly to Google Calendar is two separate jobs, not one, and almost every stubborn double booking comes from the gap between them. Separating the two makes the fix obvious.

Two jobs, not one connection

The first job is reading. A booking page has to know when the time is already committed, which means checking one or more calendars for conflicts before offering a slot.

The second job is writing. Once someone books, the event has to be created somewhere, with the guest attached and a meeting link if one is needed.

Calendly's own help documentation keeps these apart in its setup steps. Connecting a calendar account, then selecting the calendars to check for conflicts, then choosing where new bookings go, are described as distinct choices. The calendar types offered at connection time are listed as Google, Outlook or Office 365, and Exchange.

A conflict that lives in a calendar that was never selected for checking is invisible, no matter how clearly it appears on screen. That single sentence accounts for most of the surprise bookings, and it is worth reading the conflict list rather than assuming the account covers everything under it.

Connecting Google Calendar, step by step

The sequence is short. In Calendly, add a calendar connection and choose Google. Sign in to the Google account when the prompt appears, then return to Calendly. From there, pick which of that account's calendars should be checked for conflicts, and pick the single calendar where new bookings will be created.

Three details in that sequence matter more than the clicking.

The account is not the unit of truth. The conflict check is per calendar. An account holding a work calendar, a personal calendar and two calendars shared by colleagues will offer all of them, and only the ticked ones count.

The destination is one calendar. Bookings land in the calendar chosen as the destination. If that calendar is one that other people do not check for availability, the booking exists but does not defend the time against anyone else's invitation.

The connection is per Google account. A second Google account with its own commitments is a second connection, and whether that is possible depends on the plan, which is the subject of the next section.

Plan limits that decide the design

Calendly publishes the connection limits on its pricing page, and they shape the setup more than any preference does. The figures below were on that page in late September 2026.

Plan	Price as listed	Calendar connections
Free	Always free	1
Standard	$10 per seat per month	6
Teams	$16 per seat per month	6
Enterprise	Starts at $15,000 per year, from 50 seats	6

The free plan also lists one event type, one-on-one scheduling, a customisable booking page and the browser extension. Standard adds unlimited event types and the ability to connect multiple calendars. The page notes that seats are required for people who connect calendars and host meetings, while invitees do not need a seat, and that the Enterprise tier is available in US dollars only.

Reading the table with a specific setup in mind is more useful than comparing tiers in the abstract. One person, one Google account, one kind of meeting fits inside the free tier without strain. One person with a work account and a personal account does not, because the second account cannot be connected. A pair of colleagues who need bookings distributed between them is a different requirement again, since distribution across hosts sits on the Teams tier along with team scheduling.

The consequence for anyone juggling two Google accounts on a free plan is direct. One connection means one account is checked and the other is not. The commitments in the unchecked account are invisible to the booking page, and no amount of care about time zones or buffers will change that. Either the two accounts' calendars get consolidated so that one connection sees everything, or the plan has to change.

Where the gap actually opens

Six situations account for nearly every booking that lands on top of something else.

A calendar that exists but is unchecked. The most common case, and the one to rule out first.

A second account outside the connection limit, as described above.

A subscribed feed rather than a calendar in the account. Google's documentation describes two ways to connect a calendar to another application: signing in with the account, which allows view and edit, and using the secret address in iCal format, which is view only. A calendar that reached the account as a read only feed is a copy of somebody else's schedule, and copies are exactly the sort of thing a conflict check may not treat as busy.

Events marked as free. An event whose availability is set to free is a note, not a commitment, and a conflict check that respects that setting will offer the slot.

Travel between appointments. Two meetings forty minutes apart in different parts of a city do not conflict on paper. They conflict in practice, and only an event that occupies the travel time makes that visible to a booking page.

A calendar filtered out on Google's side. Google keeps a separate sync selection page in Google Calendar settings that controls which of an account's calendars are offered to other applications. A calendar unchecked there is healthy in the browser and absent everywhere else.

Availability rules do a different job from conflict checks

It helps to separate two things that both feel like protection. A conflict check removes slots that are already taken. Availability rules remove slots that should never be offered in the first place, such as evenings, Fridays, or anything inside the next two hours. Calendly's pricing page lists control over meeting availability as setting rules for when a person is available.

The two fail differently. A conflict check fails by not seeing a calendar. Availability rules fail by being generous. A window of nine in the morning until seven in the evening, five days a week, with no minimum notice, is technically correct and practically hostile, because it invites strangers into the exact hours that hold the work. Tightening the rules costs nothing and removes whole categories of awkward booking without touching any calendar setting.

Rules also carry the parts a calendar cannot know. A person who needs fifteen minutes between calls, or who never takes a first meeting before ten, is describing policy rather than a conflict. Encoding that once in the availability rules is more reliable than blocking time by hand each week and hoping the blocks were placed before somebody booked.

Making the booked event land where it will be seen

The booking is created in Google Calendar. Whether it reaches the Mac promptly, and whether it is editable when it gets there, depends on how the Mac is connected to that account.

Apple's Calendar guide describes adding accounts through Calendar and then Add Account, covering iCloud, Google and other CalDAV accounts, with a manual path for providers that are not listed. An account added that way is read and write. A calendar subscribed from a URL is read only.

Freshness has two separate controls, and mixing them up looks like a sync fault. For an account, Calendar settings has an Accounts tab with a Refresh Calendars menu per account, where choosing Push updates the account automatically when a change is made. For a subscribed calendar, the control is on the calendar itself: control-click its name, choose Get Info, and set the Auto-refresh menu. Apple's guide also notes that a warning symbol beside a published, shared or subscribed calendar means Calendar cannot connect to that calendar account, which is a real error rather than a slow refresh.

Time zones deserve a paragraph of their own, because they produce the one complaint that sounds like a sync failure and never is. A booking page offers slots in the invitee's time zone and stores the result as an absolute moment. The event arrives correctly and shows at the hour that moment represents in the calendar's own time zone. When the two people are in different countries, the meeting looks wrong to at least one of them until the time zone of the calendar, the booking page and the operating system are confirmed to agree. Nothing moved. The clocks disagreed about what to call the same instant.

One caveat applies to anyone whose main calendar is a Microsoft one. Apple's guide states that for calendars administered through Microsoft Exchange Server 2007 with Service Pack 1 or later, full calendar features are available only in the main Exchange calendar, and that additional calendars in that account do not show updated invitations or attendee responses, are not visible to delegates, and do not appear when other people check availability. A booking destination buried in a secondary Exchange calendar is therefore a poor choice, because the whole point of the destination is that the time now looks busy.

When the booking page belongs in the calendar

A separate booking service earns its place when routing matters: several hosts, round robin distribution, forms that screen who gets through, payment collection before a slot is held. Calendly's pricing page attaches most of that to its paid tiers, and for a sales or recruiting team those features are the product.

An individual consultant, trainer or freelancer often needs something narrower. Free slots computed from the calendar, a page to send, and the booking landing in the same calendar the day is run from. When that is the whole requirement, a booking page built into the calendar application removes the conflict check as a category of problem, because the application that computes the free slots is the application holding the events. There is no list of calendars to keep ticked and nothing to reconcile.

That is the shape of the scheduling page in a native Mac calendar, computed from the events already on screen, with measured travel time counted as occupied rather than free. The pricing for that approach sits on the buy page, and it is a different trade from paying per seat for routing features a solo practice will not use.

What to change first

Open the conflict settings on the calendar connection and read the list of ticked calendars out loud against the calendars actually in use. Then check that the booking destination is the main calendar other people check, not a side calendar. If the whole arrangement would be simpler with the booking page and the calendar in one place, Caltimate computes availability from the calendar it already holds.