Why your Google Calendar subscription is not updating
Someone moves a meeting. You refresh Google Calendar. Nothing changes. You refresh again the next morning and it has quietly corrected itself overnight.
Almost every report of “my subscribed calendar is broken” turns out to be this, and it is not a bug. It is worth knowing the difference between a feed that is slow and a feed that is genuinely failing, because the fixes are completely different.
First: how often does Google actually refresh?
When you add a calendar under Other calendars → From URL, Google does not
hold a live connection to it. It fetches the .ics file on its own schedule.
That schedule is not published, not configurable, and not guaranteed — in
practice people see anywhere from a few hours to roughly a day.
There is no setting to make it faster. There is no refresh button. Removing and re-adding the calendar forces one fetch, which is why that trick appears to work and then stops working the next time.
The quick test
Open the .ics URL directly in a browser. If the file that downloads
contains the corrected event, the source is fine and you are waiting on
Google. If it does not, the problem is upstream, and nothing on the Google
side will help.
When it is genuinely broken
That one test splits the problem in two. If the downloaded file is missing the change as well, work through these:
The URL requires a login. Google fetches the feed anonymously, with no
session and no credentials. A URL that works in your browser because you happen
to be signed in will fetch as an error page or an empty calendar. You need the
publicly reachable .ics link, not the one from the address bar.
The feed was re-published. Many systems mint a brand new URL each time you publish, and silently retire the old one. The old link keeps returning the last good file, or a 404, and Google keeps quietly using it. Re-copy the link.
The source only publishes a window. Plenty of systems export the next 30 or 60 days only. Events further out never existed in the file, so they cannot appear.
The file is invalid. A malformed .ics — bad timezone blocks, unescaped
characters, truncated output — may be rejected wholesale. If some events sync and
others never do, this is the usual cause.
Two symptoms people misread
Events are off by an hour. This is a timezone problem, not a sync problem. Either the feed publishes floating times with no zone attached, or it publishes in a zone that does not match your calendar’s. It will look correct for half the year and wrong the other half, which is the giveaway that daylight saving is involved.
Events are duplicated. Two subscriptions to the same source, or a subscription plus a sync, or a feed whose events change UID when the source system regenerates them. Remove one of the two paths and the duplicates stop.
What to do about the slow case
If the feed is fine and you are simply waiting on Google, you have three options.
Live with it, when the calendar is reference material rather than something you act on. Manually re-add it when you need a forced fetch, which works once and does not scale. Or stop subscribing and start syncing.
Syncing means an add-on reads the same feed, works out what changed, and writes real events into a Google Calendar you own. Because the events are yours rather than a read-only mirror, they update in realtime, and you can edit, recolour and share them like anything else on your calendar. That is what ICalSync does.
Worth checking before you change anything
Run the browser test first. It costs thirty seconds and it tells you whether you are debugging Google or debugging the source system — and those two problems have no fixes in common.
The ICalSync setup guide has a longer troubleshooting section, and what an iCal feed actually is covers the mechanics if you want the background.
Stop waiting for the refresh
Free to install from the Google Workspace Marketplace.
