Your Calendar Still Shows a Cancelled Booking
Empty room, full calendar
A guest cancels on a channel. The channel releases the dates. Your listing there shows available again.
Everywhere else — your own website, your other channels, the spreadsheet, whatever you use to see the month at a glance — those nights are still blocked. Nobody can book them. You won’t find out until you look, and most hosts look after the dates have passed.
This is the quiet cousin of double booking. Double booking is loud and embarrassing and you deal with it immediately. A stale block is silent, and it just costs you the week.
Why the block doesn’t clear itself
Calendar sync between systems is almost always one-way iCal feeds. A channel publishes a URL, other systems read it on a schedule, and every event in the file becomes a blocked date.
The problem is what a feed is. It’s a snapshot of what’s booked right now. It does not contain a list of what was cancelled. There is no “this reservation has gone away” event — the event simply stops appearing.
So a system reading that feed has to notice an absence. It has to remember what it saw last time, compare, spot that something is missing, and work out that the missing thing means “release these dates”.
Plenty of tools never do this. They read the feed, create blocks for what’s in it, and never reconcile against what they created before. Blocks go in and never come out. Over a season your calendar slowly fills with nights nobody ever booked.
The three things a feed sync must handle
A sync worth trusting handles all three of these, not just the first:
| Case | What it means | What should happen |
|---|---|---|
| Matched | The external event lines up with a booking you already have | Link them. Don’t create a second block. |
| Unmatched | The dates are sold and your system knew nothing about it | Block immediately, ask for details later |
| Vanished | Something you imported before is gone from the feed | It was cancelled upstream — remove your block |
That third row is this article. It’s also the one most likely to be missing.
The ordering of the first two matters too, and it’s the design decision we’d defend hardest: block first, ask questions later. The moment a feed shows dates as sold, they should be protected — even though the system doesn’t yet know the guest’s name or what they paid. Protection is instant; the ledger detail catches up. The other way round, you spend the gap exposed to a double booking.
The safeguard that stops it overcorrecting
There’s an obvious danger in automatically removing blocks: a feed that fails to load, or returns an empty file, would look exactly like “everything was cancelled”. Strip the blocks on that basis and you’ve just opened your entire season to booking.
So removal has to be constrained. In Airflow, a block records which feed created it and which event it came from, and only that feed’s own blocks can ever be removed by that feed’s sync. A block you made by hand, or one that came from a spreadsheet import, cannot be cleared by a calendar feed having a bad morning.
This matters more than it sounds, because empty feeds are not rare. When we pulled three real feeds to test this, one public Google Calendar returned zero events — not an error, just an empty file — because its sharing wasn’t set to show all event details. A sync that trusted that blindly would have released every date on the property.
Not all feeds tell you the same amount
While testing against real channel feeds, the difference in quality was stark, and it changes how much you can expect automation to do.
One large channel’s reservations carry a reservation reference in the event. That makes matching deterministic rather than a date-based guess — and, crucially, it survives a guest changing their dates. All four live reservations we tested matched their existing records exactly, by code.
Another channel’s feed says nothing at all. Every event reads “CLOSED - Not available”. No guest, no reference, no distinction between a real reservation and a manual block. One of the events we pulled spanned about five months — a seasonal closure, indistinguishable from a very long booking.
With the second kind, a review queue isn’t an edge case, it’s the main path. Every event needs a human to say what it was. Any tool promising fully automatic reconciliation from that feed is promising something the data cannot support.
If your calendar is wrong right now
A practical sequence:
- Find blocks with no booking behind them. These are your suspects — dates held by something nobody can name.
- Check each against the source. Is it still in the channel’s feed? If it isn’t, and the channel shows the dates available, it’s stale.
- Look at how old they are. Stale blocks cluster around cancellations, so a run of them often points at one period where a sync was failing.
- Check your feed URLs still work. A feed that has gone private or been regenerated will fail quietly, and a feed that fails quietly leaves everything it ever created behind.
- Then fix the sync, not just the symptom. Clearing today’s stale blocks by hand and leaving the mechanism unchanged means doing it again next quarter.
Airflow surfaces unexplained blocks in a review queue with three answers — add the booking details, mark it as an owner block, or ignore it — so the list shrinks instead of being re-triaged every time you look at it. The import itself runs hourly.
The underlying point
Your calendar isn’t a display. It’s the thing that decides whether a stranger can take your dates. Every stale block is a night you can’t sell, and every missing block is a double booking with a guest who has already paid.
Both failure modes come from the same root: treating a feed as a list of what’s booked, rather than as a snapshot you have to reconcile against what you believed last time.
Related: Why Your iCal Sync Keeps Breaking, Every Booking You Already Have, In One Place, One Calendar to Rule Them All, and Managing Bookings from 5 Platforms. When a cancellation reaches your books rather than your calendar, see What Happens to Your Invoice When a Guest Cancels.