How Often Do iCal Feeds Refresh, and Why Does Yours Lag?

There is no single refresh clock

Hosts ask for one clear time. They want a rule they can trust. No such rule exists for feeds. Each link in the chain has its own pace.

Your feed is a file on the web. It holds your dates in text form. An app reads that file from time to time. The app then shows the dates it found. You do not push dates to the app. The app pulls them when it is ready.

That one fact explains most lag. You can change your file at once. You can not make the app read it at once. The app picks its own time to check. It may check soon, or it may wait hours.

Schools that post feed help say the same thing. One app may refresh fast. The next may refresh once a day. Some feeds can look stuck for days. That range is wide, but it is real.

Four parts share control of the pace. No one part can set the whole pace. The table shows who does what.

The feed owner is you or your tool. You add a block or a new stay. The file updates when you save. That step is fast most of the time. It is the one step you control in full.

The file can hold a hint, too. The hint asks for a refresh pace. It is a wish, not a rule. The next part of this guide covers it.

The receiving app holds the real power. It is the guest site or the app a guest uses. It reads feeds on its own plan. It may read one feed fast and one feed slow. You can not see or change that plan.

A cache can sit in the path as well. A cache keeps an old copy of a file. It serves that copy to save time and cost. If the app gets the old copy, your new date waits. The cache clears in its own time.

This is also why sync can drift. Two sites read the same feed at odd times. One shows the new date and one shows the old. Read more on why Airbnb and Vrbo calendars fall out of sync for that case.

The refresh hint most apps may ignore

Feed files can hold a refresh hint. The hint sits near the top of the file. It tells apps how long to wait. It gives a time in plain text form.

Two forms of the hint show up in feeds. One is named X-PUBLISHED-TTL. The other is named REFRESH-INTERVAL. Both say the same kind of thing. Both ask the app to check back soon.

Here is what such lines can look like.

X-PUBLISHED-TTL:PT1H
REFRESH-INTERVAL;VALUE=DURATION:PT1H

That text asks for a check each hour. It does not force a check each hour. The word ask is the key word here. An app can take the hint or skip it.

Many apps skip it by choice. They have their own fixed pace. They read all feeds on that one pace. A hint from one small feed will not change it. The app team sets the pace to keep costs low.

Some apps set a floor as well. They will not check more than so often. Your hint can ask for five short checks. The app may still wait a full day. That is dull, but it is not a bug.

Do not chase the hint as a fix. First check that your file is right. Then check that the link still works. A right file with a slow app is not a fault. A wrong file is a fault at any pace.

You can view the hint if you open the file. Paste the feed text into a check tool. Look at the top lines of the file. If the hint is not there, that is fine. Most feeds work with no hint at all.

Say you take a new stay by phone. You block the dates on your feed at once. The hint asks for a fast check. The guest site may still show the dates as free. A guest could try to book them that night. That risk is real and it is not rare.

So treat the hint as weak help. Use it, but do not trust it alone. For key dates, act on both sides at once. Block the date in each app by hand. That step takes a bit more time. It cuts the risk while feeds catch up.

Five reasons your feed lags more than most

Some feeds lag for hours each time. The same five causes show up again and again. Work through this list from top to end. Fix the first cause you find.

1. The app reads feeds on a slow plan
2. A cache serves an old copy of the file
3. Your tool saves changes in a batch
4. The file has a fault that stops the read
5. The link points to an old feed

First, the app plan is slow. This is the top cause by far. The guest site reads feeds when it wants. Peak times can slow the read more. New hosts feel this most at first. They check each hour and see no change.

Second, a cache holds an old copy. The app asks for your file and gets the old one. Your new dates are in the new file. They are not in the copy the app got. The wait ends when the cache clears. You can not clear a cache you do not own.

Third, your own tool may batch its saves. Some tools wait and save all changes at once. You click save and think the file is new. The tool may post the new file much later. Check the file, not the screen in your tool. The file is the truth the app will read.

Fourth, a fault in the file can stop the read. One bad event can break the whole parse. The app may keep the last good set of dates. It may show old dates for days that way. No error note may reach you at all. This is the cause you can fix fast. Run the file through a check and fix each flag.

Fifth, the link may point to an old feed. You may have made a new feed last year. The guest site may still read the old one. The old feed no longer gets your new dates. Both feeds look fine at a glance. Only the dates give the fault away.

Time zones can add a false lag, too. A date may shift by a day on screen. That looks like a slow feed but is not. The feed read fine and the time math went wrong. Check the start time and the zone name. A wrong zone can move a stay by hours.

End dates can fool you as well. In feed files, the end date is the day you leave. It is not the last night you stay. If you read it as the last night, dates look off. The feed may be right and your read may be wrong. Keep that rule in mind when you check.

Note which cause fits your case. Write it down with the date and time. That note helps if the lag comes back. It also helps if you ask for help. You can point to facts, not just a bad feel. See the ICS feed troubleshooting guide for the full fault list.

What you can do about a slow feed

You can not set the pace of a guest site. You can still cut risk in real ways. These steps work for hosts of all sizes. Do them in this order for best results.

• Check the feed file first, not the guest site
• Fix all errors the check flags
• Wait, then check the guest site once more
• Block key dates by hand on each site
• Test again at set times, not all day

Step one is to check the file itself. Paste the feed text into a check tool. Or upload the file if you have it saved. Look at the dates the tool finds. If the new date is there, your feed is fine. The lag sits with the app, not with you.

You can test your feed in five minutes with a short set of steps. That test is quick and it needs no code skill. Do it each time a key date looks wrong. It splits feed faults from app lag in one pass.

Step two is to fix each flag you see. Fix errors first, then look at warnings. An error can stop a whole read. A warning may hurt just one event. Save the file and run the check once more. Stop when the check comes back clean.

Step three is to wait with a plan. Check the guest site after some hours pass. Check once more the next day if you must. Do not check each ten short spans of time. That adds stress and gives you no new facts. The app will read when it reads.

Step four guards your key dates. If a stay is new, block it by hand. Do that on each guest site you use. Hand blocks act at once on that site. They hold the date while the feed catches up. This one habit can prevent double bookings on busy weeks.

Step five is to set a test habit. Pick two set times each week for checks. Run the same quick test each time. Note the lag you see in hours. A log shows if lag grows or shrinks. It turns a vague worry into clear facts.

Keep feed links safe while you work. A feed link can hold a private token. That token acts like a key to your dates. Do not post the full link in a public place. Do not share it in a group chat. Test feeds you own or have a right to use. If a link leaks, reset it in your tool at once.

A check tool has clear limits, too. It reads the feed content you paste or upload. It flags errors and warnings in that content. It shows your events on a time line. It does not contact the guest sites for you. It can not prove a site has refreshed. No tool can prove that from the file alone. What it can prove is that your file is sound. A sound file is the part you control. Keep that part clean and the rest is just wait time.

Questions about feed refresh

Can I force a guest site to refresh my feed?

No, you can not force it. The site reads feeds on its own plan. You can fix your file and wait. For key dates, block them by hand.

Is a lag of one day a sign of a fault?

Not by itself, no. A lag of hours is normal for feeds. Some apps take a day or more. Check the file first. If the file is right, wait.

Does the refresh hint change the wait?

It can, but it may not. The hint asks the app to check back soon. The app may use its own pace and skip it. Treat the hint as a wish, not a rule.

How can I tell feed lag from a feed fault?

Check the feed file, not the guest site. If the new date is in the file, it is lag. If the date is not there, it is a fault. Fix the file and test it once more.

Sources and further reading

• Arkansas Tech University — how to subscribe to an iCalendar feed, and why refresh support varies by app
• UC Berkeley — iCal feed instructions, and notes on feeds that can look stuck for days
• Iowa State University — a plain tutorial on iCalendar feeds and how apps read them
• IETF RFC 5546 — the iTIP rules for how calendar data moves between apps
• IETF RFC 7986 — newer iCalendar properties, including REFRESH-INTERVAL, the hint a feed gives apps for how often to check it
• University of Wisconsin–Madison — publishing a calendar in Microsoft 365, and why a Google Calendar subscriber may wait up to 24 hours to see changes