# Why do two back-to-back Booking.com reservations show as one long block in iCal?

Source: https://lemon.cy/learn/merged-block-back-to-back-bookings-one-event/  
Publisher: Lemon.cy (Red Tribe Media Ltd, Limassol, Cyprus)  
Updated: 2026-09-10 · Verified against production: 2026-09-10

**Short answer:** Booking.com exports unavailable nights as ranges, so two stays where one checkout is the next check-in are often merged into one "CLOSED - Not available" event under a new UID. The middle checkout, and its clean, disappears from the feed. Lemon keeps the tracked stays, refuses to widen them, and asks the host about nights nothing explains.

## The shape of the problem

Guest A stays the 8th to the 13th. Guest B stays the 13th to the 12th of the following month. Booking.com's calendar has the property closed continuously from the 8th, so its export may emit **one** event, 8th to 12th, under one UID. Two consequences:

1. The checkout on the 13th — the one that needs a cleaner — is not in the feed anywhere.
2. If the merged block exceeds 30 nights, a duration rule that says "long, nameless block = owner closure" will skip it entirely, and a tracked reservation underneath can be silently cancelled.

Lemon's incident log has exactly this case (INC-5, September 2026): two real stays, 5 nights plus 30 nights, exported as one 35-night block. The first stay was cancelled with no cancellation source and no decision record, which is the signature of a duration skip rather than the auto-cancel engine. It was found, fixed and restored the same day.

## How Lemon handles a merged block now

- **Refuse the widen.** If a tracked booking's own UID widens to swallow another stay, Lemon does not apply the date change. It refreshes "last seen" and leaves the booking and its cleaner alone.
- **Defer the duration skip.** A normal-length tracked reservation whose block balloons past 30 nights routes to the reshape guard first, instead of being guillotined by the owner-closure rule.
- **Surface uncovered nights.** Any nights inside the merged block that no tracked booking covers are shown to the host as a `pending_review` item under a stable synthetic ID keyed on the block's checkout. The host answers once: real stay, or not.
- **Promote when the feed splits it again.** If Booking.com later exports the real reservations separately, the placeholder adopts the real event (`synthetic_promoted`) rather than blocking it.

## What a host should do

Nothing, in the normal case: the first stay keeps its cleaner. If you see a "nights nobody has claimed" card on the dashboard, answer it — that is the second stay asking to exist. If you know two stays are back to back, a direct PMS connection removes the ambiguity entirely, because the reservation objects arrive separately.

## Related

- [Merged block](https://lemon.cy/glossary/merged-block/)
- [Reshape](https://lemon.cy/glossary/reshape/)
- [Supersede](https://lemon.cy/glossary/supersede/)
- [Uncovered nights](https://lemon.cy/glossary/uncovered-nights/)
- [How are same-day turnovers scheduled?](https://lemon.cy/learn/same-day-turnover-scheduling/)
- [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/)