Most developers assume that once a user subscribes to an ICS feed the updates will simply appear. It feels like a pull version of sending calendar invites. You publish a new event. The calendar client fetches it. Everyone stays in sync.

That is not what actually happens.

Subscription behaviour is one of the least predictable parts of the calendar ecosystem. Outlook might poll once a day or once a week. Google might go quiet for days and then refresh twice in a row. Apple might fetch more often but cache the results aggressively. Some clients only re-fetch when the URL changes. Some never re-fetch at all if the server is slow or returns unexpected headers.

The result is a familiar support ticket:
 “The user subscribed and everything looked fine at first but none of the new events have appeared.”

This article explains why that happens and what you can do about it.

Why subscriptions behave differently from calendar invites

Calendar invites work because you send a payload directly to a user. The client receives it, processes it and updates the calendar immediately. The flow is controlled.

Subscriptions are nothing like that. A subscribed calendar is simply a remote ICS URL that the client decides to fetch whenever it wants. There is no standard, no promised interval and no reliable trigger.

The important point is this:
 You cannot force a refresh from the server side. The client chooses when to poll your feed and you have no control over its timing.

This is why two people can subscribe to the same feed and stay out of sync for hours or days.

The symptoms developers see

You will recognise some of these:

1. New events never appear
2. Updates to existing events arrive hours or days late
3. Older events disappear because the client only loads a window of future dates
4. Outlook users report that the feed looked correct at first but then froze
5. Google Calendar shows the feed but never refreshes unless the user deletes and re-subscribes
6. A subscription works on one device but not another

None of these are bugs in your code. They are normal behaviours of the clients themselves.

What the calendar clients are actually doing

Here is the root of the problem. Every vendor has its own approach to polling and caching.

Outlook

Outlook is the most stubborn.
 Many versions poll once every several hours. Some versions poll once a day. Some versions do not poll at all if the feed is slow to respond or if Outlook decides the URL has not changed since the last fetch.

A common bug is that Outlook caches the entire feed and keeps showing that snapshot even after your server updates the file.

Changing the URL forces Outlook to treat it as a new subscription. This is sometimes the only way to get Outlook to refresh.

Google Calendar

Google fetches feeds on its own schedule. There is no documented interval. It can be anywhere from a few hours to a few days. The first fetch is immediate but later fetches depend on internal heuristics.

If Google receives a slow response or an unexpected header it may temporarily stop polling the feed.

There is also a hard limit on how often Google will refresh large feeds.

Apple Calendar

Apple refreshes more often but still caches.
 It is also sensitive to server headers.
 Cache-Control headers matter. ETag seldom matters because many calendar clients do not respect them.

Apple sometimes re-fetches the entire file and sometimes only checks for headers. The behaviour is inconsistent across macOS and iOS versions.

The core reasons subscribed calendars stop updating

If we remove vendor quirks the underlying causes are simple.

1. Polling intervals are not standard or reliable

There is no rule that says a client must check every hour. Some clients poll less often than that. Some clients only refresh when the device wakes. Some poll more when active and less when idle.

2. Clients cache aggressively

Most clients store the entire ICS feed locally. If the feed has not changed in size or if the client believes it is unchanged it may skip re-fetching.

3. ICS files usually contain no versioning

If the feed URL stays the same the client has no obvious reason to refresh. There is no built-in version property for subscribed feeds. UID and SEQUENCE help for invites but not for subscriptions.

4. Server headers can block refreshes

Long cache times, missing Last-Modified headers, unexpected content types or rate limits can all cause a client to pause polling.

5. Large feeds trigger throttling

When a feed grows beyond a certain size some clients slow down their refresh rate to reduce bandwidth.

What developers can do to improve reliability

You cannot control the polling interval but you can make your feed easier for clients to work with.

1. Version your feed URLs

This is the most effective strategy.

Instead of serving the feed at a permanent URL like

 /calendar.ics

 serve it as

 /calendar.v1234.ics

Each time you publish major changes increment the version in the URL.
 This forces clients to treat it as a new subscription endpoint and re-fetch immediately.

This approach is widely used because it works on all major clients.

2. Keep the feed lightweight

Limit how many months of events you include.
 Long feeds cause throttling.

Most clients only need the next 30 to 90 days.
 If you push years of history into the feed you will almost guarantee slow refreshes.

3. Set appropriate caching headers

Use Cache-Control with short or moderate max-age values.
 Set Last-Modified to the time the file changed.
 Avoid overly aggressive caching on your server.

4. Provide invites for time sensitive changes

If an urgent change needs to reach a user within minutes do not rely on a feed.
 Send an email invite or API-based update instead.

Subscriptions are best for broad informational calendars.
 They are not suitable for real-time changes.

5. Consider authenticated feeds carefully

Clients often fail to authenticate properly after the first request.
 If possible keep subscription URLs public but unguessable.

A practical playbook for handling user issues

When a user reports that their feed is not updating ask these questions:

1. What client are they using
2. When did they subscribe
3. Has the feed URL changed since then
4. How large is the feed
5. Are you setting any Cache-Control headers
6. Can they remove and re-add the subscription

If Outlook is involved the answer is often “change the URL”.

If Google is involved the answer is often “wait for the next polling cycle”.

If Apple is involved the answer is usually “check the headers”.

When to stop relying on subscriptions

Subscriptions are fine for one-way information flows like school calendars, club events, staff rotas or public event listings.

They are not good for any workflow where updates must be timely and reliable.
 In those cases the correct answer is direct invites or a dedicated scheduling API.

Downloads are predictable. Subscriptions are not.

Final thoughts

Most developers expect subscribed calendars to behave like synced content. They do not.
 Polling is inconsistent across clients and caching rules are opaque.
 The only effective strategies are URL versioning, small feeds and realistic expectations.

If you build a system that relies on real-time delivery you should avoid subscriptions entirely.
 Use invites. Use APIs. Keep everything explicit.

Subscriptions belong in the “nice to have” category, not the “mission critical” one.