What you see
A guest checks in on the 17th for five nights. On the 18th the feed shows the stay as 18th to 22nd. On the 19th, 19th to 22nd. The checkout never moves; the check-in marches towards today. Booking.com is exporting "the nights that are still unavailable", and yesterday's night is no longer one of them.
Why it breaks naive software
Most calendar-driven tools treat any change to a booking's dates as a "date change" event: they update the stored dates, reset the cleaning job, and message the cleaner that the booking changed. Do that once a day for every in-progress stay and cleaners learn to ignore the messages. Worse, if the tool builds any identifier from the check-in date, the identity changes nightly and the stay appears to vanish and reappear — the mechanism behind a whole family of false cancellations Lemon fixed in 2026.
Lemon's rule
An already-elapsed check-in is immutable, for every feed. No platform may move an arrival that has already happened. When the feed shows an in-progress stay with a later start date, Lemon keeps the stored check-in, refreshes "last seen", and logs an elapsed_checkin_pinned decision. Nothing else changes: no job reset, no cleaner message, no "dates changed" alert.
A second rule makes this safe: only the checkout drives the clean. A change to the check-in alone — elapsed or not — never touches the cleaning job, because the job is scheduled at the checkout time.
Scale
Because Booking.com trims on almost every export, the pin fires on almost every five-minute fetch of every in-progress stay. Between 2026-09-05 and 2026-09-10 Lemon logged 1,240 elapsed_checkin_pinned decisions across its feeds. That is not 1,240 problems — it is one behaviour, observed continuously, handled silently.