Guide

Calendar Sync vs Calendar Subscription: The Difference That Costs You Time

Subscribing to a calendar's ICS feed and syncing two calendars are different operations. Pick the wrong one and events lag by hours, are read-only, or disappear.

Published

If you have ever added someone else’s calendar to your own Google or Outlook and noticed the events showed up but you could not edit them, congratulations: you have used a calendar subscription. If you have ever used SyncCal, OneCal, CalendarBridge, Reclaim’s calendar sync, or similar, that was a calendar sync.

They look the same in the UI. They behave completely differently.

What a calendar subscription actually is

A calendar subscription is a one-way, polling-based, read-only feed. The mechanism:

  1. A calendar publishes an .ics URL (the iCalendar standard, RFC 5545).
  2. Your calendar app remembers that URL.
  3. Every few hours, your calendar app fetches the URL and re-imports whatever events it finds.
  4. The events appear in your calendar but cannot be edited; the source URL is the source of truth.

Common examples: sports team schedules, conference agendas, public holidays, your colleague’s calendar shared with you read-only.

Refresh interval is usually 6 to 24 hours. Google Calendar refreshes ICS subscriptions every 8 to 24 hours per Google’s own docs. Outlook is similar. You cannot force a refresh in most clients.

What a calendar sync actually is

A calendar sync is a two-way (or configurably one-way) bridge that uses each calendar’s native API to push and pull events in near-real time:

  1. The sync engine connects to each calendar via OAuth (Google, Microsoft) or CalDAV (iCloud, Yahoo, Fastmail, self-hosted).
  2. When you create or edit an event on calendar A, the engine writes the change to calendar B via API call.
  3. Bidirectional sync repeats in the opposite direction.
  4. Webhook subscriptions on Google and Microsoft trigger updates within seconds; CalDAV uses short-interval polling for the same effect.

End-to-end propagation is 30 to 90 seconds depending on the providers involved.

Why the difference matters

You want a subscription when:

  • The source calendar genuinely is read-only data (sports, holidays, conference).
  • You do not need the events on your calendar to influence booking tools that read your free/busy.
  • A refresh delay of hours is acceptable.

You want a sync when:

  • The source calendar holds events you actively edit.
  • A booking tool reads your calendar and needs your conflicts up to date.
  • You want changes to propagate in seconds, not hours.
  • You want two-way: edit on either side, see the result everywhere.

The trap people fall into

The most common failure mode: someone tries to use an ICS subscription as a Calendly conflict calendar.

Calendly reads one calendar to detect conflicts. If you subscribe your personal Google to your work Outlook (via ICS), the personal events show up in Outlook with a multi-hour lag. Calendly reads Outlook and sees those personal events. So far so good.

Then you add a new personal commitment. It does not appear in Outlook for 8 to 24 hours. Calendly does not know about it. Calendly books a prospect call on top of it. You apologize and reschedule.

A real sync engine (SyncCal, OneCal, CalendarBridge, etc.) writes the event to Outlook via the Microsoft Graph API in seconds. Calendly sees it within a minute. The double-book never happens.

This is why Calendly misses conflicts on your other calendars recommends sync, not subscription, for the conflict calendar setup.

When sync is overkill

Some cases really are subscription cases:

  • A public team schedule that you want to glance at but never edit.
  • A holiday calendar from your country or religious tradition.
  • A conference agenda that the organizer publishes.
  • Your kid’s school calendar from the district website.

For these, an ICS subscription works fine and is the right tool. Adding a full sync would be over-engineering and would waste API quota.

How to tell which one you have

In Google Calendar:

  • Subscriptions appear under “Other calendars” in the left sidebar. The icon is a small clipboard-like shape.
  • Calendars you own (and that sync tools write to) appear under “My calendars”.

In Outlook:

  • Subscriptions appear under “Other calendars”. You cannot create or edit events on them.
  • Calendars you can write to are under your own account in the “My calendars” group.

In Apple Calendar:

  • Subscriptions appear in their own group with a generic icon.
  • Your own iCloud calendars are under your iCloud account section.

If you cannot create an event on a calendar in your app, it is a subscription. If you can, it is either yours or a synced mirror.

What SyncCal does

SyncCal is an event-level sync, not a subscription. For each calendar pair you set up, SyncCal uses the native API on both sides and propagates changes in seconds. See the CalDAV glossary entry for the protocol details and the webhook entry for why webhook-based sync is dramatically faster than poll-based subscription.

For setting up a real two-way sync between common pairs:

If you need to PUBLISH a subscription (rather than consume one), the ICS format is the right tool. We cover that in Share your calendar without showing details under “Method 3: Publish a busy-only ICS feed”.