Five reasons an event goes missing
- The guest cancelled. The night range is open again and the export no longer lists it.
- Re-key. The same nights are still exported, under a new UID. Booking.com does this routinely.
- Merge. The nights are still exported inside a wider block that also covers a neighbouring stay.
- Glitch. The platform served an empty or partial file this time. It will be back on the next fetch.
- Dead link. The iCal URL expired or was regenerated; every event is gone and stays gone.
Only the first should cancel a cleaning job. A tool that reacts to absence alone gets all five wrong in the same way.
How Lemon tells them apart
- Empty feed — treated as a failed fetch. Nothing changes. (Rules out 4 and, for the first fetch, 5.)
- Bulk disappearance — more than half of a feed's future bookings gone at once, at least three of them: hold everything. (Rules out 4 and 5 at scale.)
- Re-key adoption — a vanished UID whose checkout still appears under an unclaimed UID is re-linked. (Rules out 2.)
- Still-covered check — a Booking.com booking whose remaining nights are still inside a wider generic block is not missing. (Rules out 3.)
- Confirmation window — what remains accrues observed absence: 24 hours normally, 2 hours within three days of checkout, never within 24 hours. (Handles 1 with a margin for anything the rules missed.)
The other failure direction
Being conservative has a cost: a booking that really was cancelled can be kept too long. Lemon documents the ways a booking can become "immortal" — a host's "Keep it" hold, a feed that was deleted and re-added, a placeholder row awaiting an answer — and gives each one a visible state on the dashboard rather than letting it hide. A "Keep it" hold re-raises itself for review after 7 days.
What a host should look at
If a booking is flagged "possibly cancelled", open the platform. If the reservation is there, press "Keep it" and check whether the iCal link is still valid. If it is genuinely cancelled, confirm it — the cleaner is told immediately.