Why your Google–Outlook sync keeps dropping events

You set up a sync between Google Calendar and Outlook, watched a few events flow across, and moved on. Then one Tuesday you show up to a meeting that isn’t on the other calendar — or worse, you don’t show up, because the event silently vanished. Nothing errored. Nothing warned you. An event was just… gone.

Dropped events are the most common and most damaging way calendar sync fails, precisely because they’re invisible. A duplicate is annoying but obvious. A missing event looks exactly like an empty slot. Here’s why it happens, and what a sync tool has to get right to stop it.

1. Expired sync tokens fall back to a partial view

Neither Google nor Microsoft re-sends your whole calendar on every check. They hand out a sync token (Google) or delta token (Microsoft) that means “give me only what changed since last time.” It’s efficient — and fragile.

These tokens expire. Google returns a 410 Gone when a sync token is too old; Microsoft invalidates delta tokens after a period of inactivity. When that happens, a sync engine has to throw the token away and perform a full re-sync from scratch. If it instead treats the error as “nothing changed” and keeps polling with a dead token, every edit you make from that point on is invisible to it. Events you create never propagate. Events you delete on one side never get deleted on the other.

2. Webhook subscriptions quietly expire

“Real-time” sync is built on push notifications: the provider pings the sync service whenever something changes. But those subscriptions are short-lived. Google’s calendar channels last days; Microsoft’s subscriptions cap out around three days and must be renewed before they lapse.

If a service registers a webhook and forgets to renew it, real-time sync just… stops. No error surfaces to you — the subscription expires server-side and the pings stop arriving. Everything you change during that window is dropped until something else triggers a full reconciliation. This is why a sync that “worked great for the first week” can go cold.

3. Rate limits get swallowed instead of retried

Both providers throttle aggressively. Google returns 403 rateLimitExceeded; Microsoft returns 429 Too Many Requests with a Retry-After header. These are expected under load, not exceptional.

A sync engine that treats a throttle the same as a permanent failure — logging it and moving on — drops every event in that batch. Done right, a 429 means “wait the number of seconds I told you, then try the exact same write again.” The events that get lost here aren’t lost because of a bug in calendaring; they’re lost because retry was treated as optional.

4. Recurring events and their exceptions

A weekly standup isn’t 52 events — it’s one recurrence rule plus a handful of exceptions: the week it moved to Thursday, the week it was cancelled, the week the room changed. Google and Microsoft model these differently, and the mapping is where naive sync tools fall apart.

The usual failure is dropping the exceptions. The series copies across fine, but the one-off “this week we’re meeting at 2 instead of 10” override is lost — so the other calendar confidently shows the wrong time. A cancelled occurrence that doesn’t carry over leaves a meeting on your calendar that everyone else knows isn’t happening.

5. All-day events and timezones

All-day events have no time, only a date — and the two providers disagree on how to represent that. Convert it through a timezone carelessly and a one-day event lands on the wrong day, or slips off the edge of the sync window entirely and never appears. Same story for events near midnight across a timezone boundary: round the wrong way and they fall outside the range being queried.

6. Two-way sync loops that delete to “fix” themselves

This is the dangerous one. In a two-way sync, a copied event has to be recognizable as a copy, or the engine sees its own writes as foreign changes and reacts to them. Without solid identity mapping, you get echo loops — and some tools “resolve” the resulting mess by deleting events on both sides. You don’t end up with five copies of every meeting; you end up with none.

What actually fixes it

None of these are exotic. Reliable sync comes down to handling the boring cases correctly:

• Treat token expiry (410/invalid delta) as a trigger for a full re-sync, never as “no changes.”
• Renew webhook subscriptions before they expire, and run a periodic safety-net re-poll to catch anything the push channel missed.
• Honor Retry-After and back off on 429/403 — then retry the same write, don’t abandon it.
• Model recurrence rules and their per-occurrence exceptions, not just the base series.
• Normalize all-day and timezone handling explicitly instead of trusting a default conversion.
• Give every synced event a stable identity mapping so the engine never mistakes its own writes for user changes.

A missed meeting isn’t the kind of bug you want to discover after the fact. If you’ve been fighting a sync that drops events, the fix isn’t a louder reminder — it’s an engine that handles the cases above without you having to think about them.

That’s the whole reason twocal exists. We do one thing — keep your calendars in sync — and we treat every item on that list as table stakes, not a roadmap.