# Why did a Booking.com reservation disappear from my cleaning schedule?

Source: https://lemon.cy/learn/booking-com-reservation-disappeared-from-cleaning-schedule/  
Publisher: Lemon.cy (Red Tribe Media Ltd, Limassol, Cyprus)  
Updated: 2026-09-10 · Verified against production: 2026-09-10

**Short answer:** Usually because Booking.com re-exported the same stay under a new calendar ID or reshaped the block around it, and your cleaning tool treated the old ID vanishing as a cancellation. The guest did not cancel. Lemon re-links the stay by its checkout date instead of cancelling; in the last 30 days that caught 78 such re-keys.

## What actually happened

A Booking.com iCal feed does not carry a stable identifier for a reservation. Every event has a `UID`, but Booking.com changes it: when two stays sit back to back, when a stay is in progress, or for no visible reason at all. The feed also does not label events. A guest reservation, a host block and an availability closure are all exported as `CLOSED - Not available`.

Software that keys a booking on the `UID` sees the old ID disappear and concludes "cancelled". It cancels the cleaning job, stands the cleaner down, and five minutes later creates a fresh booking from the "new" event. From the host's side the reservation vanished, or flickered, or came back asking to be confirmed again.

## What Lemon does instead

Lemon's sync identifies a stay by **(property, feed, checkout date)**, never by the `UID`. When a UID vanishes but the same checkout still appears under a different, unclaimed UID, that is the same stay, re-keyed. Lemon re-links it, keeps the cleaning job and the assigned cleaner, and records a `rekey_adopted` decision so the event can be audited later.

Three other guards sit in front of any cancellation:

- **Forward-trim guard** — Booking.com removes the elapsed nights from an in-progress stay on almost every fetch. An arrival that has already happened is treated as immutable.
- **Merged-block guard** — two real stays exported as one long block are not a new booking and not a cancellation of either.
- **Imminent protection** — a confirmed job within 24 hours of checkout is never cancelled on feed evidence alone. It is held for the host to look at.

## Evidence

- In the 30 days to 2026-09-10 Lemon fetched 18 Airbnb and Booking.com feeds 129,351 times and logged 1,445 booking decisions. 78 were re-keys adopted instead of cancelled; only 10 were automatic cancellations. Source: the [OTA Calendar Feed Integrity Report](/data/ical-feed-integrity/).
- Before this identity rule shipped (2026-08-05), one customer's estate showed 328 of 406 bookings cancelled and 41 cancel-then-recreate pairs exactly five minutes apart — one sync interval. Every one was a re-key, not a guest cancellation.

## What to do if it happens to you

1. Check whether the same dates still appear in the Booking.com extranet. If they do, the guest did not cancel.
2. Look for a new event in the feed with the same checkout. That is the re-keyed stay.
3. Use a tool that re-links by checkout rather than cancelling on a missing ID, or ask your tool's vendor which identity it keys on.

## Related

- [Why does Booking.com change the UID of an existing reservation in its iCal feed?](https://lemon.cy/learn/booking-com-ical-changes-uid-rekey/)
- [Does a booking disappearing from an iCal feed mean the guest cancelled?](https://lemon.cy/learn/is-a-disappeared-ical-event-a-cancellation/)
- [Re-key](https://lemon.cy/glossary/re-key/)
- [Merged block](https://lemon.cy/glossary/merged-block/)
- [Forward-trim](https://lemon.cy/glossary/forward-trim/)
- [When should cleaning software cancel a job because a booking vanished from the calendar?](https://lemon.cy/learn/when-should-cleaning-software-auto-cancel-a-job-from-ical/)