Fix bookings that never reach your calendar, outside events that fail to block time, duplicate entries, and connections that quietly stopped working.
Calendar sync runs in two directions, and almost every sync complaint is really a problem with one direction or the other. Cal ID reads your calendars to work out when you are busy, and it writes confirmed bookings onto one calendar you nominate. Deciding which direction is broken takes about thirty seconds and narrows the fix immediately.
”Check for conflicts” and “add events to” are different settings
Getting these two confused is the single most common cause of calendar-sync confusion, so it is worth being precise about them before anything else.
Check for conflicts
Add events to
Direction
Cal ID reads the calendar
Cal ID writes to the calendar
What it decides
Whether events on that calendar remove slots from your booking page
Where a new confirmed booking is created
Where you set it
Settings → Calendars — a tick box per sub-calendar
Settings → Calendars for the account default, and the event type’s Advanced tab for a per-event override
How many can be on
Many. Every ticked sub-calendar is checked.
One per event type. A booking is written to exactly one calendar.
Symptom when wrong
Double-booked over an event Cal ID could not see
The meeting is somewhere you never look
Choosing a destination calendar under Add events to calendar does not narrow conflict checking. Cal ID still reads every sub-calendar you have ticked for conflicts. Likewise, ticking a calendar for conflicts does not make it a destination. If you want a calendar to both block your time and receive bookings, you must set both.
A worked example. You keep three Google sub-calendars: Work, Personal, and a subscribed Holidays feed.
Tick Work and Personal for conflicts, leave Holidays unticked — your own commitments block bookings, but public holidays you do not observe do not.
Set Add events to calendar to Work — every booking lands in one predictable place.
A dentist appointment on Personal still removes the slot, even though no booking will ever be written there.
The booking exists in Cal ID — you can see it under Bookings — but nothing arrived on the calendar itself.
The booking is still awaiting confirmation
An event type with Requires confirmation turned on creates a pending booking. Cal ID does not write a pending booking to your calendar, because you have not accepted it yet.Go to Bookings at https://cal.id/bookings and open the Unconfirmed tab. Accept the meeting and the calendar event is created immediately.Related: Require booking confirmation
No destination calendar is set
If no calendar is connected — or the event type points at a connection that has since been removed — Cal ID has nowhere to write.
Open the event type, go to the Advanced tab, and check the Add events to calendar dropdown. An event type can override the account default here, and duplicated event types carry the override with them.
Attendees still receive their confirmation email with a calendar invitation attached, which is why this often goes unnoticed until you find your own calendar empty.
You are looking at the wrong sub-calendar
In Google Calendar and in the Unified Calendar, each sub-calendar has a visibility tick box in the left sidebar. If the destination calendar is toggled off, its events are on your account but invisible in the view you are looking at.Toggle every calendar on in the sidebar and look again before assuming the event was never created.
The write silently failed on an expired connection
A connection whose token has expired can still appear in the list while failing every write. Bookings pile up in Cal ID and none of them lands.Work through The connection is broken or its permission was revoked below, then create a test booking on a spare slot to confirm writes are flowing again.
Something is on your calendar, but Cal ID offered the slot anyway and you got double-booked.
1
Confirm the event is marked Busy
An event set to Free — the default for many all-day events, birthdays, and subscribed feeds — is deliberately ignored. Change it to Busy on the calendar itself.
2
Confirm the event's sub-calendar is checked for conflicts
Go to Settings → Calendars at https://cal.id/settings/my-account/calendars and expand the connection. Each sub-calendar has its own tick box, and a conflict on an unticked sub-calendar is invisible to Cal ID.
Newly created sub-calendars are not ticked automatically. If you made a new “Client work” calendar last week and it has not blocked anything since, this is why.
3
Check that you declined nothing
An invitation you declined is generally not treated as busy time. If you intend to attend, accept the invitation or add a separate blocking event.
4
Check how far ahead the sync reaches
Cal ID pulls in your meetings from the past 30 days and the next 90 days. A conflict far outside that window may not be reflected in the Unified Calendar view even though it exists on the source calendar.
5
Verify with the troubleshooter
Open https://cal.id/availability/troubleshoot and select the date. If the event does not appear as a busy block there, Cal ID genuinely cannot see it — the cause is one of the four steps above, not a booking-page problem.
Cal ID writes each booking to exactly one calendar, chosen in this order of precedence:
The Add events to calendar value on the event type’s Advanced tab, if one is set.
Otherwise, the destination calendar set in Settings → Calendars.
So a single event type behaving differently from the rest almost always has a per-event override. Open its Advanced tab and either point it at the right calendar or clear the override so it follows the account default.
Changing this setting affects new bookings only. Meetings already on the wrong calendar stay where they are — move them by hand on the calendar, or cancel and rebook if attendees need a fresh invitation.
If bookings land on the right calendar but under an unexpected account, check which email address the connection uses. Connecting a personal Google account and a work Google account produces two separate entries in Settings → Calendars, and they are easy to mix up when both are simply labelled “Google Calendar”.Related: Add events to calendar
Reconnecting a calendar without removing the old connection can leave two live connections to the same account. Both write, so every booking is created twice.Go to Settings → Calendars, look for two entries with the same email address, and remove the one you do not want. Delete the duplicate calendar events by hand afterwards — removing a connection does not clean up events it already created.
You are both the host and an attendee
If your own email address was added to a booking through the Add guests field, you receive the invitation as a guest and Cal ID creates the host event. Two entries, one meeting.Remove your own address from the guest list when booking. This most often happens while testing your own booking link.
A third-party sync tool is also copying the event
Calendar mirroring tools, phone accounts syncing the same calendar twice, and automation platforms that create a second event from a Cal ID webhook all produce apparent duplicates.Check whether the duplicate is identical or slightly different — a different title, colour, or organiser points at an external tool rather than at Cal ID. Review anything you have wired up under Apps → Installed Apps at https://cal.id/apps before changing calendar settings.
The booking was rescheduled and the old event survived
A reschedule updates the existing calendar event. If the connection was briefly unavailable, the update can land as a new event while the original remains.Cancel the stale event on the calendar and confirm the surviving one matches the time shown under Bookings → Upcoming at https://cal.id/bookings — treat Cal ID as the source of truth.Related: Cancel or reschedule a booking
The connection is broken or its permission was revoked
A calendar connection can lapse without you touching anything: a password change, a workspace admin revoking third-party app access, an Apple app-specific password regenerated, or a permission declined during the original consent screen.The tell-tale sign is a sudden change with no matching action on your side — either everything reads as busy, or nothing does.
Reconnect the calendar. On the consent screen, grant all requested permissions — view, create, edit, and delete. Withholding delete permission, for example, leaves cancellations stranded on your calendar with everything else appearing to work.
4
Re-select your sub-calendars
After reconnecting, tick the sub-calendars you want checked for conflicts and confirm the destination calendar. These choices are not always carried over, and a reconnected calendar with nothing ticked blocks nothing.
5
Test in both directions
Add a Busy event on your calendar for a bookable slot and confirm the slot disappears from your booking page. Then make a test booking and confirm it lands on the destination calendar. Cancel both afterwards.
Disconnecting a calendar stops Cal ID from checking it for conflicts, so slots it used to block become bookable straight away. Do not disconnect a calendar as a diagnostic step during working hours unless you have hidden your event types first.
Reconnecting restores the connection; it does not replay history. Set expectations accordingly.
Conflict checking resumes immediately. As soon as the sub-calendars are ticked, your booking page reflects the busy events on them.
Existing events are re-read, not re-created. Cal ID pulls the past 30 days and next 90 days of events for availability. Nothing on your calendar is modified.
Bookings taken while the connection was down are not back-filled. Any confirmed booking that failed to write stays missing from the calendar. Find them under Bookings and add them manually, or cancel and rebook if the attendee needs a fresh invitation.
Slots that were wrongly offered stay booked. If the outage caused a double-booking, resolve it yourself by rescheduling — Cal ID will not undo a confirmed booking.
Per-event overrides survive. Any event type with its own Add events to calendar value keeps it, so check those event types individually if the connection you replaced was their destination.
After any reconnection, make one test booking on a slot you do not mind losing and then cancel it. It takes a minute and it verifies read, write, and delete permissions in a single pass — which is exactly the set that silently breaks.