You blocked those nights for a good cause. A fix, a rest, or a stay for kin. Then the block is gone. The nights show as free. A guest books them, and your plans clash at once. Few faults scare hosts more than this one.
Blocks do not vanish by magic. Each block is data, and data can break. This guide shows how a block is built, why it can fail on one site and not the other, and the midnight trap in date-only blocks. It ends with steps to make blocks that last.
A block is an event, and events can break
To a feed, a block is not a lock. It is just an event, like a stay. It has a start date and an end date. It has an ID and a name. The site that reads it treats it as dates to close. If the event is sound, the dates close.
If the event breaks, the dates open. A break can be small. The end date may be missing. The ID may clash with a stay ID. A line may be cut or hold odd marks. The site that reads the feed may drop that one event. It keeps the rest. You lose just those nights.
A block can also be cut at the source. You set it in one tool, then switch tools. The new tool makes a fresh feed with no block in it. The block was real in the old tool. In the new feed, it was never there. The next read wipes it from each site.
Edits can cut a block by chance too. You drag a stay to a new date. The drag clips the block next to it. You change a rule for stay length. The rule wipes short blocks as a side effect. You may not see the loss at the time. You see it when a guest books the freed night.
Some blocks have a set life span. A tool may drop old events to keep the feed small. If your block sits far in the past in part, a trim can clip its start. A clipped block may fail a read. Or it may show for fewer nights than you set.
The fix starts with one habit. Treat each block like a booking. Give it the same care as a paid stay. Set it at the source. Check it in the feed. Check it in the guest view. A block you check is a block that lasts. A block you set and forget is a risk.
- A block is an event, not a lock
- One bad line can make a site drop it
- A tool switch can leave a block behind
- Edits near a block can clip it by chance
- Check blocks with the same care as stays
Once you see a block as an event, your checks get clear. You ask the same things you ask of a stay. Is the ID sound? Are both dates there? Does the time line show the right nights? Those three asks find most lost blocks fast.
Why blocks vanish on one platform but not the other
Hosts ask this a lot. The block shows on site A. It is gone on site B. How can one feed give two results? The feed is the same. The reads are not the same. Each site reads in its own way and on its own clock.
One site may read the feed each few hours. The other may read once a day or less. A new block shows on the fast site first. On the slow site, the night stays free for hours more. That gap is normal, but it can sell a night if a guest is quick.
Sites also treat weak events in their own ways. One site may skip a flawed block and load the rest. The other may fail the whole feed on that same flaw. In the first case, you lose one block. In the second case, you lose all new data. Both look like a vanished block from your chair.
Filters play a part too. Some sites read only paid stays from a feed. They may treat a block with a blank name as no stay at all. Some tools write blocks with a word some sites do not map to closed dates. The block is in the feed. The site just does not close the dates for it.
This is part of how calendars fall out of sync as a whole. Blocks are the most felt form of drift. A lost stay is a mess. A lost block is a mess that sells itself to a new guest. That is why blocks need the first check after each sync.
| Cause | Where to look | Fix |
|---|---|---|
| Slow read | Time since last read | Wait, then check again |
| Flawed event | Block event in the feed | Fix dates and ID at source |
| Blank name | Name line of the block | Give the block a clear name |
| Whole feed fails | All dates froze at once | Fix the first feed error |
| Hand block | Where you first set it | Reset it in the source tool |
Work the table from top to bottom. Check the time gap first, since it costs no fix. Then check the block event in the feed text. Then check the name and the source. If all dates froze, the fault is file-wide, not block-wide. See why imports keep failing for that case.
Keep a note of which site lags for you. Patterns help. If one site is slow each time, plan for it. Set blocks a day early in peak weeks. Do not trust a fresh block on that site until you see it in the guest view.
Date-only blocks and the midnight trap
Most rental blocks use dates with no times. That form is clean and clear. It also has a trap at midnight. The trap frees or blocks one night more than you meant. Hosts fall in it all the time, and the fault looks random at first.
Here is the rule. For a date-only event, the end date is the day the block ends. The guest can book that night. So a block from the tenth to the twelfth closes two nights. It closes the tenth and the eleventh. The twelfth is free that night. If you meant to close three nights, your end date must be the thirteenth.
Hosts often set the end date as the last closed night. That is the plain way to think of it. But the feed does not work that way. It treats the end date as the first free day. One short end date frees your last night. A guest books it, and you think the block vanished. In truth, the block was one night short from the start.
Midnight and time zones make this worse. A timed block that ends at midnight can land on the wrong day. If the zone is off, midnight in the feed is not midnight at your home. The block can end a day early in local time. Date-only blocks dodge the zone trap, which is one cause to favor them.
Test your blocks with a small case. Set a block for two nights next month. Check the feed end date by hand. Then check both sites in the guest view. Count the closed nights one by one. If the count is short by one, your end date rule is off. Fix the rule in the source tool, not just that block.
- The end date is the first free day
- Count closed nights one by one in guest view
- Timed blocks near midnight need zone care
- Date-only blocks dodge most zone traps
- Fix a short count at the source rule
This trap also hits stays, not just blocks. A stay that ends a day short frees a paid night. A stay that ends a day long blocks a free night. Learn the rule once, and you read all your dates with new eyes. Your time line checks will catch this in seconds from now on.
How to make a block that survives sync
A strong block has four traits. It lives at the source. It has clean dates and its own ID. It has a clear name. And you have seen it in the guest view on each site. Blocks with all four traits rarely vanish. Blocks that miss one trait are the ones that go.
Step one: set the block at the source. The source is the one tool that makes your feed. Do not set key blocks by hand on a single site. A hand block lives on that site alone. The next feed read can wipe it or fail to send it on. Source blocks travel with the feed to all sites.
Step two: set the dates with the end rule in mind. Start on the first closed day. End on the first free day. Count the nights out loud as you set them. Add a day if the count feels short. Then save and look at the saved block with fresh eyes.
Step three: give the block a clear name. Use plain words like Blocked for repairs. A name helps sites map the event to closed dates. A name helps you spot the block in a feed too. Blank names blur into the list and get missed in checks.
Step four: check the feed. Paste or upload the feed to a checker. Find your block in the list of events. Check its start, its end, and its ID. Scan the time line and count its nights. CalendarCheck flags feed errors and shows that time line. It does not contact the booking sites, so you still need step five.
Step five: check the guest view on each site. Wait for a fresh read first. That wait can be hours, since each app sets its pace. Then open each site as a guest. Try to book each blocked night. Each try should fail, since the night is closed. If one site lets you start a booking, the block has not landed there yet.
- Set the block in the source tool
- Set the end date as the first free day
- Give the block a clear plain name
- Check the block in the feed and time line
- Test each night in guest view on each site
For homes you must keep closed at all costs, add a belt to the braces. Close the nights in the source. Check them as above. Then check them once more the next day. A second look catches a slow read that fooled the first look. It takes two minutes and buys real peace of mind.
If a block still goes missing, check the feed link and the feed health. A feed that comes back blank gives sites no block to load. Read about a feed that comes back empty or shows a 404 if your dates all froze at once. Fix the feed first. Blocks cannot sync from a feed that will not load.
Keep feed links private through all of this. A feed link can hold a private token. Share it only with sites you must. Only test feeds you own or may use. The free preview in CalendarCheck covers one feed monitor. Paid Multi-feed covers up to ten monitors, with daily checks and email alerts. Alerts can warn you when a feed breaks, so a lost block gets found in a day, not by a guest.
Questions about blocked dates
My block shows on one site but not the other. What now?
Wait for a fresh read on the slow site first. Then check the block event in your feed. If the event is sound and time has passed, reset the feed link on the slow site. Recheck the guest view after that.
Why did my block come back one night short?
That is the end date trap in most cases. The end date is the first free day, not the last closed night. Set the end one day later to close that last night. Then recheck the count in guest view.
Can I block dates by hand on each site to be safe?
You can, but it adds risk of its own. Two hand blocks can clash with the feed. One source block that syncs is cleaner than two hand blocks. If you do block by hand, log it and clear it when the source block lands.
How will I know if a block breaks in the future?
Check blocked nights in your weekly routine. Look at the guest view, not just the host view. Daily feed checks with alerts help too. They flag a broke feed fast, before a guest books the freed nights.
Sources and further reading
- IETF RFC 5545 — the core iCalendar format for events, dates, and times.
- Northern Illinois University — how to import an iCalendar file of holidays as events.
- UC Berkeley — iCal feed instructions, with notes on feeds that can look stuck.
- U.S. Office of Personnel Management — the federal holidays set by law (5 U.S.C. 6103) that holiday calendars are built from
- Quinnipiac University — what iCal is, and how long subscribed events typically take to sync