Do not connect a new feed on faith. A feed can look fine and still hold faults. One bad event can break an import. One wrong date can free a booked night. A five-minute check now saves hours of stress later.
This guide gives you a clear order to work in. Start with the file itself. Then run the checks that matter most. Then read the time line, not just the text. Last, fix the source and check again, so the fix lasts.
Start with the file itself
A feed is a plain text file. You can open it in any text app. It should not look like a web page. It should not start with page code or ads. If it does, you have the wrong link or the wrong file.
The file holds one or more events. Each event sits in its own block. The block starts with one line and ends with one line. Lines have names in caps, then a colon, then a value. Once you know the shape, the file feels less strange.
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
UID:stay-1042@example.com
DTSTART;VALUE=DATE:20261218
DTEND;VALUE=DATE:20261220
SUMMARY:Booked
END:VEVENT
END:VCALENDARRead that small block with care. The UID is the ID for that one event. It must stay the same each time the feed is read. The start date says when the stay starts. The end date says when the stay ends. For date-only stays, the end date is the day the guest leaves.
Check the top and tail of your real feed. The top should name the file type and version. The tail should close the last event and the file. A file cut off at the tail is a bad sign. It may mean the feed broke while it was made.
Check the size too. An empty file is a clear fault. A tiny file for a full season is a doubt. A huge file with years of old stays may be slow to read. Size will not tell you all, but it gives a fast first clue.
Note what app made the feed. That app is your source. If you find a fault, you fix it there. Do not edit the feed text by hand to ship it. The next read will wipe your hand edit. Fix the source, then make a fresh feed.
If you want the full rules for a sound file, read what makes an ICS file valid. That guide lists the fields each event needs. Keep it open as you do your first checks. You will learn the shape fast.
- The feed should be plain text, not a web page
- Each event needs a start line and an end line
- Each event needs its own stable UID
- A cut-off tail means the file may be broke
- Fix faults at the source, not in the text
The checks that matter most
You cannot check each line by eye for long. So check the lines that break feeds most. Five checks catch most faults. Run them in this order each time. The order goes from file-wide faults to event faults.
Check one: each event has a UID. No UID means apps cannot track that event. Two events with the same UID is just as bad. One will hide or wipe the other. Each stay and each block needs its own UID for life.
Check two: each event has a start and an end. A start with no end is a top cause of failed reads. The end must come after the start. An end on the same day as the start, for a date-only stay, means zero nights. That frees the night you meant to block.
Check three: dates use the right form. Date-only dates have eight digits and no time. Timed dates have a time and, in most feeds, a zone mark. Do not mix forms in one event. A start with a time and an end with no time will trip most apps.
Check four: each event has a stamp line. That line tells apps when the event was made or changed. Apps use it to tell new data from old data. A missing stamp can make an app skip the event. A stamp far in the past can make fresh data look old.
Check five: text lines are not broke. Long lines get folded in this format, by rule. A fold done wrong can cut a word or a date. Odd marks in a name or note can also break a line. Keep names short and plain if you can.
| Check | Good sign | Bad sign |
|---|---|---|
| UID | One clear ID per event | No ID, or same ID twice |
| Start and end | End comes after start | No end, or end too soon |
| Date form | Same form for start and end | Forms mixed in one event |
| Stamp | Recent stamp on each event | No stamp at all |
| Lines | Short, clean, whole lines | Cut words or odd marks |
A tool speeds this up a lot. CalendarCheck checks ICS feed content you paste or upload. It flags errors and warnings for you. That is how CalendarCheck inspects a feed from start to end. Use the flags as a work list. Fix the first error, then run the check again.
Do not chase warnings first. Errors break reads. Warnings hint at risk. Clear all errors, then work through warnings in order. Some warnings will not apply to your use. Note those and move on. Your notes help the next check go fast.
Read the timeline, not just the text
A feed can pass each line check and still be wrong. The facts can be wrong in a clean file. That is why you need to see events in time. A time line puts each stay in its place. Your eye can spot what text hides.
Look for overlaps first. Two stays should not share a night. If they do, one of them has a wrong date. Or a block was lost and a new stay took its place. Mark the clash and go back to the source to see which stay is true.
Look for gaps next. A gap is a free night in the midst of a full week. It may be real, a true free night. It may be a fault, a stay that ends a day too soon. Check gaps near peak dates with extra care. Those nights sell fast if they show as free.
Look at start and end days with care. Guests leave on the end date in date-only feeds. That day is free for the next guest that night. New hosts misread this rule a lot. They think the end date is the last night of the stay. That one-day slip blocks or frees a night by mistake.
Look at blocks too, not just stays. Each block should sit on the nights you meant to close. A block for a fix should start on the fix day. It should end when work ends, not a day late. A long block can hide open nights you could have sold.
Compare the time line to a source you trust. Use your booking list or your own notes. Pick five stays at random and match each date. Pick all blocks in the next month and match them too. Five true matches build trust fast. One mismatch means you check all, not just five.
- Overlaps mean a wrong date or a lost block
- Gaps in a full week need a second look
- The end date is the day the guest leaves
- Check blocks with the same care as stays
- Match five stays to your own records
This step takes the most time by eye. It is worth each minute. Most hosts who find a costly fault find it here. The text looked fine. The time line told the truth. Make this step a habit before you connect any new feed.
Fix the source, then check again
Found a fault? Good. Now fix it in the right place. That place is the app that made the feed. Open the stay or block there. Fix the date, the time, or the name there. Save it, then make a fresh feed and check that fresh feed.
Do not patch the feed file by hand. A hand patch feels fast. It dies at the next read. The source still holds the fault. The fault will come back on a busy day, when you can least spare the time. Source fixes last. Hand patches do not.
Fix one fault at a time if you can. Check again after each fix. This feels slow, but it shows you cause and effect. If two fixes go in at once and the feed gets worse, you will not know which fix hurt. One by one is the calm way to work.
Some faults need a read of the fix steps. See how to find and fix broken events for event-level repairs. That guide goes deep on broke events. Keep your check list by your side as you use it. Mark each event off as it passes.
After fixes, run the full check once more. Start with the file shape. Run the five key checks. Scan the time line again. Do not skip steps just since the feed passed once. A fix in one place can break a new place. The full pass takes minutes and proves the feed is sound.
Only then should you connect the feed. Paste the feed link in the new site or tool. Wait for that app to read it. That read can lag by hours, since the app sets the pace. Check the guest or host view after a wait. Compare three stays to your source before you trust it.
Make this check a habit, not a one-off task. Run it each time you add a new home. Run it each time you change tools. Run it when a guest reports a wrong date. Each run takes less time than the last. You learn the shape of a sound feed. You learn the signs of a weak one. Soon you will spot a fault in a feed at a glance, the way you spot a typo in a short note.
Keep the checked feed text and your notes. Save the date of the check. Save the list of faults you fixed. If a fault comes back next month, your notes show if it is the same one. Past notes turn a new scare into a known fix.
- Fix the fault in the source app
- Make a fresh feed from the source
- Run the full check again
- Connect the link, wait, then verify dates
- Save your notes for the next check
If time is short, use a five-minute feed test as your fast pass. It covers the top checks in a tight order. Use the full guide here when you connect a new feed or move tools. Use the fast test for weekly spot checks. Both have a place in a calm routine.
A last word on privacy. Feed links can hold private tokens. Keep your links private. Paste feed text only in tools you trust. Only test feeds you own or may use. If you share a feed text for help, cut the token part out first. Safe habits here cost you nothing.
Questions about checking a feed
What is the first sign a feed is bad?
The top signs are an empty file, a cut-off tail, and events with no end date. Any one of them should stop you. Fix the source first. Do not connect a feed with those signs.
Do warnings mean I must not connect the feed?
Not always. Errors mean stop and fix. Warnings mean look and judge the risk. Some warnings matter for rentals. Some do not. Note the ones you accept, so you recall why later.
How often should I check my feed?
Check before you connect a new feed. Check after you change tools or date rules. Check once a month in a calm week. Peak hosts may check more. A short check beats a rare long one.
Can I check a feed without sharing my link?
Yes. You can paste or upload the feed text itself. You do not need to share the live link. Keep the link and its token private. Share text only with tools you trust.
Sources and further reading
- IETF RFC 5545 — the core iCalendar format for events, dates, and times.
- Iowa State University — a tutorial on iCalendar feeds and how events are shared.
- Indiana University — how iCal feeds and linked calendars work in practice.
- U.S. National Archives, Records Express — guidance on calendar formats and keeping records sound.
- IETF RFC 6868 — how quotes and line breaks are encoded in iCalendar parameter values, a quiet source of syntax errors
- University of Wisconsin–Madison — step-by-step subscribing to a published calendar in Google Calendar, Outlook, and Apple Calendar