# When should cleaning software cancel a job because a booking vanished from the calendar?

Source: https://lemon.cy/learn/when-should-cleaning-software-auto-cancel-a-job-from-ical/  
Publisher: Lemon.cy (Red Tribe Media Ltd, Limassol, Cyprus)  
Updated: 2026-09-10 · Verified against production: 2026-09-10

**Short answer:** Only after a booking has been absent from a healthy feed for a full confirmation window: 24 hours when checkout is more than three days away, 2 hours within three days, and never within 24 hours of checkout. Lemon also holds when a feed is empty or loses half its bookings at once. In 30 days: 10 cancellations, 11 holds.

## Why this is the most dangerous decision in the system

iCal has no "cancelled" event. A stay simply stops appearing. Acting on a disappearance is therefore inference, and the two ways to be wrong are not symmetric:

- A **false cancel** stands a cleaner down. The guest arrives to a dirty apartment. The host loses the review and possibly the listing.
- A **false keep** sends a cleaner to an empty flat once.

Everything below is built to make the first mistake rare, accepting the second as the price.

## The state machine Lemon uses

1. A booking present in the feed vanishes while the feed is otherwise healthy. It is flagged **possibly cancelled** — a badge on the host dashboard; the booking stays `confirmed`, the job stays assigned.
2. Each subsequent fetch that still does not show it adds observed absence to a clock. One fetch can add at most 10 minutes, so an outage between fetches does not count.
3. If it reappears, the flag clears silently.
4. If the clock reaches the window, the cancellation is confirmed: jobs and offers are cancelled, the confirmed cleaner is told (with a 24-hour dedup so one cleaner is not told twice), and the host gets one grouped alert per sync cycle.

## The windows

| Time to checkout | Window before cancelling |
|---|---|
| More than 3 days | 24 hours of observed absence |
| 3 days or less | 2 hours of observed absence |
| 24 hours or less | Never on feed evidence — held for host review (`imminent_protected`) |

The last row inverts what most tools do. Giving imminent bookings the shortest fuse is exactly why damage always lands the night before a turnover.

## Things that stop the clock entirely

- **Empty feed** — treated as a failed fetch; nothing changes.
- **Bulk disappearance** — more than 50% of a feed's future bookings gone at once, and at least 3 of them: assume a platform glitch and hold. The minimum count matters: a feed with one booking would otherwise be permanently jammed at "100% missing".
- **Re-key adoption** — the same checkout appears under a different UID: not missing at all.
- **Host hold** — the host pressed "Keep it". Re-raised for review after 7 days rather than cancelling.

## Evidence

September 2026, 30 days, 18 feeds: 10 `auto_cancelled`, 11 `imminent_protected`, 78 `rekey_adopted`. Full table in the [feed integrity report](/data/ical-feed-integrity/).

## Related

- [Why should a turnover job never be auto-cancelled within 24 hours of checkout?](https://lemon.cy/learn/never-auto-cancel-inside-24-hours-of-checkout/)
- [Does a booking disappearing from an iCal feed mean the guest cancelled?](https://lemon.cy/learn/is-a-disappeared-ical-event-a-cancellation/)
- [Possibly cancelled](https://lemon.cy/glossary/possibly-cancelled/)
- [Imminent window](https://lemon.cy/glossary/imminent-window/)
- [Bulk-disappearance guard](https://lemon.cy/glossary/bulk-disappearance-guard/)
- [Host hold](https://lemon.cy/glossary/host-hold/)