Your guest site shows no dates at all. Or it shows an error and stops the sync. Both signs point to the feed link. The link may be dead, or the file may be blank.
Do not guess which fault you have. Open the link and look at what comes back. What you see tells you the fix. This guide walks you through each case. Each case gets its own clear first step.
Two errors that look the same but are not
On a guest site, both faults look alike. The site shows no new dates. It may show a blank set of dates. It may keep old dates and add none. From that screen, you can not tell the cause.
The feed link is where the truth sits. Open the link in a fresh tab. Read what the server sends back. You may get a 404 page. You may get a blank file. You may get a log in page. Each reply means a quite distinct thing.
A 404 is a code the server sends. It means the file is not found there. The link points to a place with no file. No app can read dates from no file. The sync fails at the first step.
An empty file is a distinct case. The link works and a file comes back. The file just holds no events at all. An app reads it and finds zero dates. It may clear your dates or add none. Both moves can scare a host fast.
A third case fools a lot of hosts. The link sends back a log in page. That page is web page text, not feed text. The app tries to parse it as a feed. It fails, since the text is not a feed. This is a common cause of a dead sync.
The table sums up the four replies. Find the one you see and start there.
| What you get | What it means | First move |
|---|---|---|
| 404 page | File not found | Get a fresh link |
| Empty file | Zero events in file | Check feed settings |
| Login page HTML | Wrong content type | Use the public feed link |
| Old events only | Stale file or cache | Check the source feed |
Old events only is the fourth case. The file loads and has events in it. All of them are old and none are new. That points to a stale source or a cache. The link lives, but the file no longer updates. Treat it as a link fault, not a date fault.
Once you know the case, do not stop there. You still need to check the feed for errors once it loads. A file can load and still hold bad events. Load first, then parse, then fix dates. That order keeps your work clean and fast.
Why feeds go empty
An empty feed has a cause you can find. The file loads, but it holds no events. Some change cleared the events out. Work through the list and test each step.
First, the feed source may have no dates. You may have picked the wrong set of dates. A feed can be set to one home only. If you test the feed for the wrong home, it looks blank. Check the home name in your tool first. Then check the date range the feed covers.
Some feeds hold just the next few months. Old stays drop off the file over time. If all your stays sit past that range, the file looks blank. Add a test stay in the near term. See if that stay shows up in the file. If it does, the feed works as set.
Second, a filter may hide all events. A tool may let you hide some event types. If you hide blocks and stays at once, none are left. The file will be a blank shell with no events. Open the feed text and look for event blocks. A shell has a start and an end, but no events. That shape is a clear sign of a filter fault.
Here is the shape of a shell with no events.
BEGIN:VCALENDAR
VERSION:2.0
END:VCALENDARThird, the tool may have paused the feed. A plan change can pause feeds in some tools. A bill fail can pause them as well. The link stays live but the file goes blank. Check your plan and bill state in the tool. Fix that first if you find a block.
Fourth, you may have cleared dates by hand. A bulk delete can wipe a whole set of dates. If you did that by chance, the feed is right. It shows the blank set you made by hand. Restore the dates from a back up if you can. If not, add the key stays back one by one.
Fifth, the file may fail to parse at all. A parse fail can look like an empty file. The events are there but the app finds none. Bad line breaks or bad text can cause this. A check tool will flag the fault for you. It counts the events it can parse, not just the text. Zero parsed events with full text means parse faults. Fix those faults and the events come back.
Empty feeds hurt in a quiet way. A guest site may read the blank file as truth. It may open all your dates at once. That is a real risk for double books. Act fast when you see a blank file. Block key dates by hand while you fix it. Read why blocked dates disappear if blocks went missing too.
Why links rot: moves, tokens, and resets
Feed links rot over time for plain reasons. A link that worked last year can die today. No one needs to break it on purpose. Small changes in your tools can kill it.
The top cause is a move in your tool. You may move a home to a new tool. You may merge two homes into one. You may change the home name or its ID. Each move can change the feed link. The old link then points to no file. Guest sites that use it get a 404.
A reset is the next big cause. If you reset a feed link, the old link dies. The tool makes a fresh link with a new token. That is the point of a reset, after all. It keeps old links from working any more. But each guest site still holds the old link. You must paste the new link in each place. Miss one place and that sync stays dead.
Tokens are the part of the link that rots most. A feed link can hold a private token in it. The token acts like a key for that feed. If the key changes, the link fails at once. If the key leaks, you should reset it fast. Just plan the reset when you have time to update. Update all guest sites in the same hour.
Keep feed links private while you work. Do not post a full link in a public post. Do not send it to a group you do not trust. Test just feeds you own or may use. A leaked link lets others see your dates. Treat the link like a key to your home.
Account changes can rot links as well. If you close an old account, its feeds die. If a staff login made the feed, check who owns it. If that login goes, the feed may go too. Move feeds to an account you will keep. Note the owner name in your own log.
Typos are a dull but real cause. One wrong char in a pasted link can kill it. A space at the end can break some links. Paste with care and test right after you paste. Do not type a long link by hand at all. Copy it from the tool each time you need it.
Guest sites can add their own rot. A site may drop a feed you no longer use. It may store the link in a form you can not see. If a sync dies and the link tests fine, ask the site. They can check the link they hold on file. It may not match the link you think they hold. That is also a common reason why imports keep failing for weeks.
Keep a small log of your feed links. Note the home, the tool, and the date you set it. Note each guest site that uses that link. When a link rots, the log shows what to fix. You will not have to hunt from scratch. A log turns a panic into a short task list.
Fix the link, then prove it works
Fix the fault you found, in this order. Get a live link first, then prove the file works. Do not skip the proof step at the end. A link that loads is not yet a good feed.
- Get a fresh feed link from your tool
- Paste it with care, with no extra space
- Open it and check what comes back
- Run the file through a check tool
- Paste the link in each guest site
- Check dates on each site the next day
Start in the tool that owns the feed. Find the feed or export page for that home. Copy the full link from that page. Do not use an old link from a past note. Notes go stale and links rot in time. A fresh copy from the tool is the safe base.
Next, open the fresh link in a new tab. You should see plain feed text, not a web page. The text should start with a calendar head line. It should hold event blocks for your stays. If you see a log in page, the link is wrong. Go back and find the public feed link instead.
Then run the file through a feed check. Paste the feed text in, or upload the file. The check flags errors and warnings for you. It shows your events on a time line as well. Fix each error it flags and run it once more. Stop when the count of events looks right.
A check tool reads the content you give it. It does not contact the guest sites for you. It can not prove a guest site refreshed. What it proves is that your file is sound. A sound file plus a live link is your part done. The guest site does its part when it reads.
Now paste the link in each guest site. Do them one at a time and save each one. Note the time you saved each link. Then wait for the sites to read the feed. That wait can take hours, as feeds lag by design. Check the dates on each site the next day.
If the file is blank, go back to the source. Add a test stay a few days from now. Save and open the feed link once more. If the test stay shows, the feed works fine. The blank file meant no dates in range. You can delete the test stay when done.
Close the job with a short log note. Write the date, the fault, and the fix you made. Write which sites you pasted the link into. That note is gold if the link rots again. You will fix it in half the time next time. Slow, plain steps beat fast guesses each time.
Questions about empty feeds and 404 errors
Is a 404 the same as an empty feed?
No, they are two distinct faults. A 404 means no file was found at the link. An empty feed means a file came back with no events. The first needs a fresh link. The rest needs a source fix.
My feed opens but has no events. Why?
The source may have no dates in range. A filter may hide all event types. The tool may have paused the feed. Add a near test stay and check again.
I got a log in page, not feed text. What now?
That link needs a login, so apps can not use it. Find the public feed link in your tool. Paste that link in each guest site. Test it in a fresh tab first.
How do I know the fix worked?
Open the link and see feed text with events. Run the file through a check with no errors. Then see your dates on the guest site. Wait a day for that last step.
Sources and further reading
- IETF RFC 5545 — the core rules for the iCalendar file format and its parts
- Indiana University — how iCal feeds and linked calendars work in real use
- Iowa State University — a plain tutorial on iCalendar feeds and how apps read them
- University of Wisconsin–Madison — campus event and holiday feeds, where a search returns only events in the future
- University of Portland — a calendar platform guide noting that feeds import once a day, overnight, so new events can look missing until then