When calendar sync breaks, the temptation is to disconnect and reconnect. Sometimes that works, and when it does you learn nothing, so it breaks again next month.
Almost every failure falls into one of nine causes, and they are cheap to eliminate in order. The first question is which direction is broken, because that alone halves the list.
Bookings are not appearing on your calendar. That is the write direction: the connection, the write target, or a permission on the destination calendar.
People are booking over times you are already busy. That is the read direction: which calendars are being checked, how those events are marked, and how fresh the data is. If this is your problem, read double booking prevention afterwards, because the goal is to stop the class of problem, not just this instance.
Symptom To Cause, At A Glance
| Symptom | Most likely cause | First thing to check |
|---|---|---|
| Everything worked until a specific date, then nothing | Access revoked or expired | Connection status on the integrations screen |
| Stopped the day you changed your password | App-specific password invalidated | Generate a new app password |
| Bookings confirm but appear nowhere | Written to a calendar you are not looking at | The nominated write calendar |
| Some personal events block, others do not | Events marked free, not busy | Show as setting on one that failed |
| A whole day is blocked that should not be | An all-day event treated as busy | All-day handling setting |
| A meeting you declined still blocks you | Declined events counted as busy | Your response status on that event |
| Everything is off by exactly one hour | Timezone or daylight saving mismatch | Profile timezone versus calendar timezone |
| New blocks take a few minutes to apply | Normal polling interval | Wait one interval before investigating |
| Reading works, writing gets an error | Read-only access to that calendar | Your permission on the shared calendar |
1. Expired Or Revoked Access
Symptom: sync worked perfectly, then stopped dead on a particular day. Nothing since that date has synced in either direction. The integrations screen usually shows the connection as needing attention, though not every tool surfaces it prominently.
An OAuth connection holds a refresh token, and that token can be invalidated without anyone doing anything obviously wrong. Common triggers: you revoked the app in your account security settings, an administrator revoked it centrally, the account password changed, the connection went unused for months, or the account was suspended.
Fix: reconnect. There is no repair, because the credential is gone. Afterwards, check whether the trigger was a routine security policy, because if it was, this will recur on a schedule and you want an alert on connection status rather than a customer telling you.
2. Passwords And App Specific Passwords
Symptom: the same dead stop, but on a CalDAV or iCloud connection, and it lines up with a password change.
CalDAV connections authenticate with stored credentials rather than a token. For iCloud, that must be an app-specific password, and every app-specific password on an Apple ID is invalidated when the Apple ID password changes. The same pattern applies to Fastmail and Nextcloud app passwords when their sessions are revoked.
Fix: generate a new app-specific password and re-enter it. If the connection is being rejected the very first time you set it up, you are almost certainly using your main account password, which will never work on iCloud. The full setup sequence is in CalDAV and iCloud calendar sync.
3. The Wrong Calendar Is Selected
Symptom: bookings confirm, the client gets a confirmation, and the event is nowhere in your calendar app. Or: you blocked out an afternoon and the booking page ignored it.
This is the most common cause overall, and it is really two settings that people assume are one. A calendar account holds several calendars, and a scheduling tool asks two independent questions: which calendars count as busy, and which single calendar receives bookings.
Typical mistakes: personal commitments live on a Personal calendar but only your primary calendar is ticked as a conflict source. Or bookings are written to a dedicated Bookings calendar that is not itself ticked as a conflict source, so the tool cannot see its own events and will double-book. Or the calendar is hidden from view in your phone app but present in the account.
Fix: open the integration settings and read both lists carefully. Tick every calendar that represents real commitments, including the one bookings are written to. Then, in your calendar app, confirm that calendar is set to visible.
4. Events Marked Free Instead Of Busy
Symptom: some of your events block bookings and some do not, with no obvious pattern.
Every calendar system has a per-event setting that says whether the event consumes your time. Google calls it Show as, with Busy and Free. Outlook offers Free, Working elsewhere, Tentative, Busy and Out of office. In the underlying file format it is a single property that is either opaque, meaning busy, or transparent, meaning free.
Availability checks exclude free events on purpose, because that is what the setting means. The trap is that several things default to free: all-day events in some clients, events created from certain email flows, and anything a colleague marked free before inviting you.
Fix: open one event that failed to block and look at its Show as value. If it says Free, that is your answer, and the correction is to set important blocks to Busy rather than to change how the sync works. If your workflow depends on free events blocking bookings, you are fighting the format and should use a separate calendar instead.
5. All Day Events And Multi Day Blocks
Symptom: an entire day is unbookable when it should not be, or a day of leave is fully bookable when it should not be.
All-day events are stored differently from timed events: they carry a date with no time, and their end date is the day after the last day they cover. That off-by-one representation is correct per the specification and is a reliable source of confusion.
Worse, the meaning is ambiguous. A birthday, a public holiday abroad and a week of annual leave are all all-day events, and only one should stop people booking you. Tools therefore choose, and they choose differently: some ignore all-day events, some block the whole working day, some block only if the event is marked busy.
Fix: find the all-day handling setting and set it to match how you use your calendar. If you keep holidays and birthdays on the same calendar as your leave, split them: put genuine unavailability on a calendar that is checked, and the noise on one that is not. For predictable closures such as a Christmas shutdown, a date-range availability rule in the scheduling tool is more reliable than an all-day event, because its meaning is unambiguous.
6. Declined And Tentative Invitations
Symptom: a meeting you declined weeks ago is still eating a slot, or a tentative hold is blocking a real booking.
Declining an invitation does not necessarily remove it from your calendar. Depending on your settings it stays visible, usually struck through. Whether it still counts as busy depends on how the sync reads the calendar: an availability query typically respects your own response status and excludes declined events, whereas a raw read of every event sees it like any other unless the integration filters on your response.
Tentative is a related judgement call. Microsoft distinguishes tentative from busy explicitly, so a tool can decide whether a provisional hold blocks a booking.
Fix: check your own response status on the offending event. If declined events are blocking you, turn off showing declined events in your calendar, or look for a setting in the scheduling tool for how to treat them.
7. Timezone Mismatches
Symptom: everything is consistently wrong by a whole number of hours, or it was correct until the clocks changed.
There are at least four timezones in play: your profile timezone in the scheduling tool, your calendar account timezone, the timezone your browser reports, and the client's timezone. If your profile says one thing and your calendar says another, every event lands displaced by the difference.
The variant that appears twice a year is a daylight saving problem, where an offset was stored instead of a zone name. An event stored as "14:00 at UTC+1" is wrong the moment the clocks change; an event stored as "14:00 in Europe/London" is not.
Fix: line up your profile timezone with your calendar timezone first, then retest. The mechanics, including the twice-yearly edge cases, are in timezone handling in scheduling.
8. Sync Lag Versus A Real Failure
Symptom: a change you just made has not shown up, and you are trying to decide whether to panic.
Google and Microsoft can push a notification when something changes, which usually means seconds. CalDAV is polled, which usually means minutes.
Fix: before diagnosing anything, wait one full polling interval and reload. If it appears, that was not a failure. If lag is a real operational risk for you, the answer is not faster sync, it is a minimum notice period long enough that nobody can book inside the sync window. Fifteen minutes of required notice removes the entire category of problem on a polled connection.
9. Sharing Permissions That Are Too Low
Symptom: reading works fine, and writing fails. Bookings confirm in the tool but never land on the shared or team calendar.
Shared calendars come with graded permissions. Google offers see free/busy only, see all event details, make changes to events, and manage sharing. Microsoft offers availability only, limited details, full details, editor and delegate. Writing an event needs at least an edit-level role, and being able to see a calendar is not the same as being able to write to it.
The free/busy-only level has its own trap: the calendar contributes busy time correctly, so the read direction looks healthy, while every write fails.
Fix: ask the calendar owner to raise your permission to a level that allows changes, then reconnect so the tool re-reads what it can do. If the calendar is a Microsoft room mailbox, remember it also has its own booking policy, which can refuse a request that your permissions would otherwise allow.
Preventing The Whole Class Of Problem
Three habits remove most repeat incidents. Get an alert when a connection drops rather than hearing it from a customer. Keep one calendar per meaning, so leave, holidays and bookings stay separable. And test the read direction on the day you set anything up, by putting a block on your calendar and reloading your public booking page.
appntmnts flags a broken calendar connection on the dashboard and stops offering slots it can no longer verify rather than guessing. The supported calendar systems are listed on the integrations page. If the connection is new rather than newly broken, start from Google Calendar two way sync, since half of these symptoms are a setup step that was skipped.