One event breaks and the whole feed fails.
You do not need to fix the whole file. You need to find the one bad event. This guide shows a calm way to do that. It shows the fixes that last as well.
Find the event that breaks the file
Start with proof, not with a guess. Run a check on the whole file first. The check will list errors and warnings. It will point to lines and events as well.
Write down the UID of each bad event. Write down its start date as you see it. Those two facts let you find it fast.
If you have no check result yet, bisect the file. Split the events into two halves on paper. Test each half as its own small file. The bad half will fail the test again.
Split the bad half into two once more. Test each part as its own small file. Keep going till one event stands alone. That event is the one that breaks the file.
This method feels slow but is quite fast. Ten steps can sort a thousand events well. Each test cuts the search space in half.
Look at the event just before the failure point. Some apps stop at the first bad event they hit. The event they name may be fine in itself. The flaw may sit in the block just above it.
Check the wrap of that block with care. Does it start with BEGIN:VEVENT in the file? Does it end with END:VEVENT in the file? A missing end line breaks the next event too.
Compare the bad event to a good one. Put them side by side on your screen. Match each line in one to the other block. The missing or odd line will stand out fast.
- UID line present and unique
- DTSTAMP line present in UTC
- DTSTART line in the right form
- DTEND line present and later
- SUMMARY line short and safe
CalendarCheck checks content you paste or upload. It flags errors and warnings for each event. It shows an event timeline for the file too. That view helps you spot the odd stay out.
Keep the raw file as you found it first. Save a copy before you change a thing in it. It also lets you roll back if a fix fails.
Do not work from a file a guest sent you. Work from a fresh export of your own feed. Guest copies can be old or cut short in transit.
Note the time you took the fresh export. Note the tool and home it came from too. Feeds for two homes can look much alike. A clear note stops a mix-up mid-fix.
Once you find the event, name the break. Is the date wrong or is a line gone? Is the UID a dup or is text unescaped? A named break leads to a clean fix.
The five breaks you will see most
Five breaks cause most of the failed feeds. You will meet them again and again as a host. Learn their signs and their fixes by heart.
| Break | Sign | Fix |
|---|---|---|
| No end date | Stay lasts one day | Add DTEND at the source |
| Bad date form | Event gets skipped | Use year month day form |
| Dup UID | One stay hides the next | Give each event its own UID |
| End before start | App rejects the event | Set end after the start |
| Bad text marks | Title splits or gets cut | Escape commas and semicolons |
Break one is a missing end date line. The event has DTSTART but no DTEND at all. Some apps show it as a one-day stay then. Your last nights then look free to book.
Fix it in the source stay record first. Set the check-out date for that stay there. Export the file and confirm DTEND is present. Confirm it shows the day of exit as well.
Break two is a date in the wrong form. The file may show Dec 20 or 20/12/2026. Apps need year, month, then day in digits. They need no slashes, dashes, or month names.
This break often comes from a hand edit. It can also come from a sheet export gone wrong. Fix the date in the source tool, not the copy. Then export a fresh file from that tool.
Break three is a duplicate UID value. Two stays share the same ID in the file. The app may keep one and drop the other. It may merge them into one wrong stay.
Dup UIDs grow when stays are copied by hand. They grow when a tool clones a stay record. Delete the clone and make a fresh stay instead. Each stay needs its own record and ID.
Break four is an end before the start. The DTEND date sits before DTSTART in the file. This can happen when years flip in Jan. It can happen when dates are typed by hand.
Check the year on both dates with care. Check the end date rule once more as well. The end is the day the guest leaves you. It is not the last night of the stay.
Break five is bad marks in text fields. A comma or semicolon lacks its escape slash. A long title runs past the line limit too. The title then splits, or part gets cut off.
Shorten long titles in the source record first. Keep guest names and codes out of titles. Use plain words like Guest stay or Blocked.
You can read what makes the file valid for the full list. Keep that guide open while you fix each break. Work down the list from top to base.
Time zone breaks form a close sixth case. A TZID name may be wrong or unknown there. A UTC mark may sit on a local time there. Both flaws shift a timed event by hours.
Daylight saving makes zone flaws worse in spring. Clocks move in spring and in fall each year. An event near the shift needs a close look. Check its zone name before you trust its time.
Fix at the source, not in the copy
The copy is the file you exported last. The source is the tool that built it. Fixes in the copy last till the next export. Fixes at the source last for each export.
Open the stay in the tool that made it. Change the dates or title in that tool. Save the stay and wait for it to sync. Then export or fetch a brand new file.
Do not open the copy in a text app to fix it. Text apps can change line ends in the file. They can break folded lines in the file too. They can save text in a wrong code set.
A hand fix can look right to your eye. It can still fail in a strict app that reads it. Worse, the next export wipes it out in full. You then face the same break once more.
Some flaws live in tool settings, not stays. The tool may export dates in a local form. It may omit the end date by default there. It may reuse IDs when stays get cloned.
Check those settings if the same break returns. Fix the setting once and the break stops. Note the setting you changed in your log. Tell support that fact if you need help.
If a third-party tool builds your feed, tell them. Send them the UID and the start date you noted. Send them the error text from your check too. Do not send them your full feed link in public.
Feed links can hold private tokens in them. Keep your link private when you seek help. Share a redacted copy of the bad event instead. That copy gives proof with no risk to you.
Only fix feeds you own or may use in work. Do not edit a feed that is not yours to change. Ask its owner to fix it at their source tool. Offer them the error list to help them start.
While the fix is in flight, block dates by hand. Block the sold nights in each app you use. That manual block guards you from a double sale. Remove it once the feed proves sound again.
Work on one home and one feed at a time. Fixes for two homes can cross in your notes. Finish, prove, and log the first home fully. Then move to the next home on your list.
Use check the whole feed for errors after each fix. A source fix can shift other events as well. A fresh check shows the full new state at once.
- Change the stay in its source tool
- Save and let the tool sync first
- Export a brand new file to test
- Block sold nights by hand till then
- Keep feed links out of public posts
This path takes a few mins more up front. It saves hours of repeat fixes down the line. Hosts who fix copies fix them again and again.
Prove the fix worked
A fix is not done when you click Save. It is done when proof says it held well. Proof has three parts in this work flow. Do all three before you trust the dates.
Part one is a clean check on the fresh file. Run the same check you ran at the start. The errors for that event should be gone now. No new errors should appear in its place.
Warnings may still show on other events there. Triage them, but do not hide them from view. Note each one and set a date to fix it. Small warnings now can grow to errors later.
Part two is a look at the timeline view. Find the fixed stay in that view by date. Check its start and its end in the view. Check the nights it blocks are the right ones.
Look at the stays just before and after it. A fix can push dates into a clash there. It can also open a gap that should stay shut. Neighbors tell you if the fix fits in place.
Part three is a check in the target app. Import or refresh the feed in that app now. Find the fixed stay in the app by date. Compare its dates to your source list with care.
Know what this proof cannot show for you. A tool cannot prove a platform refreshed a feed. CalendarCheck does not contact Airbnb or Vrbo at all. Only each platform can confirm its own refresh time.
Give platforms time to refresh the feed link. Some refresh in hours, some take far longer. Check the last refresh time the app shows you. Do not re-export in a panic before that time.
Run the five-minute test as your final pass. It covers count, dates, and timeline in one go. It is fast enough to run each week for each home.
If proof fails, go back one step, not to zero. Re-check the source stay you just changed there. Confirm the saved dates are what you meant to set. Export once more and run the check again.
If the same event breaks a third time, escalate. The flaw may sit deep in the tool settings. Read the full ICS troubleshooting guide for that case. It works from the tool out to each app in order.
The free preview covers one feed monitor for you. Paid Multi-feed covers up to ten monitors in full. It adds daily checks and email alerts as well. Alerts catch the next break while you sleep.
Log the fix as soon as proof passes in full. Note the UID, the break, and the fix you made. Note the date and the check result as well.
| Step | What to check | Pass sign |
|---|---|---|
| File check | Errors on the fresh file | Old errors are gone |
| Timeline | Start, end, and neighbors | No gap and no clash |
| Target app | Dates in the live app | Dates match the source |
Fixed and proved beats fixed and hoped each time. Your nights are money and guest trust in full. Take the extra mins to prove each fix you make. That habit keeps double sales off your books.
Questions about fixing events
Can I fix the file in a text app?
You can view it there, but do not save fixes. Text apps can break line ends and folds. Fix the stay in its source tool instead.
What if I cannot find the bad event?
Split the file in half and test each half. Keep splitting the bad half till one remains. That one event is the break point.
Why did the same break come back again?
The fix was made in a copy, not the source. The next export brought the old flaw back. Fix the source record and its settings.
How soon will apps show the fixed dates?
It varies by app and by refresh time. Check the refresh time the app shows you. Give it time before you export once more.
Sources and further reading
- IETF RFC 5545: iCalendar — the core rules for ICS files
- NIST: daylight saving time — when clocks shift in spring and fall
- NIST: local time FAQs — plain facts on local time zones
- Indiana University: iCal feeds and linked calendars — how feeds and linked calendars work
- IETF RFC 6868 — the caret encoding that safely carries quotes and line breaks inside parameter values
- NIST: time and frequency FAQs — official answers on time zones, daylight saving time, and how clocks keep time