Vrbo cancellation handling for cleaners: the silent-drop pattern and why most tools miss it

TL;DR: When a guest cancels on Vrbo, the booking does not get marked STATUS:CANCELLED in the iCal feed. It silently disappears. Sometimes a Blocked event appears covering the same dates; sometimes nothing does. Naive sync tools either miss the cancellation entirely or delete the job so late that the cleaner has already been dispatched. Good handling requires detecting the Blocked replacement, applying a grace window for transient iCal hiccups, and closing the Jobber job without firing a false "job completed" notification. If you run Vrbo turnovers through Jobber, this is the pattern that causes cleaners to show up at locked properties.

Why this matters: the dispatcher panic scenario

You sync Vrbo bookings into Jobber. A checkout happens Monday morning. Your scheduler dispatches the cleaner at 11 AM. The cleaner drives 20 minutes to the property, finds it locked, calls the owner. The owner says, "That guest cancelled Friday. Didn't you get the notice?"

You check the Vrbo iCal feed. The booking is gone. It was there Thursday; it's gone now. Your sync tool never told you. The cleaner invoices you for the drive time. The owner asks if you have your systems under control.

This is not a rare edge case. I built CleanSync for a cleaning company that ran into this pattern weekly once they crossed six Vrbo properties. The sync tool they were using before (a popular iCal-to-calendar bridge) would catch the cancellation anywhere from six hours to two days after it happened. By then the scheduler had already committed labor.

The root cause is how Vrbo handles cancellations in the iCal standard. Airbnb does it one way; Vrbo does it another. Most sync tools assume the Airbnb pattern and fail silently on Vrbo.

How Airbnb cancels: explicit STATUS:CANCELLED

When an Airbnb guest cancels, Airbnb keeps the booking in the iCal feed and sets STATUS:CANCELLED. The UID stays the same. The DTSTART and DTEND stay the same. The SUMMARY stays the same. The only change is the STATUS field.

A sync tool polls the feed, sees STATUS:CANCELLED, closes the Jobber job, removes the visit from the cleaner's schedule. Clean, explicit, no ambiguity.

This is how the iCal RFC says cancellations should work. Airbnb follows the spec.

How Vrbo cancels: silent UID deletion

Vrbo does not follow the same pattern. When a Vrbo guest cancels, Vrbo removes the booking UID from the feed entirely. One poll it's there; the next poll it's gone. No STATUS:CANCELLED. No tombstone. Just absence.

Sometimes Vrbo inserts a Blocked event covering the cancelled booking's dates. Sometimes it doesn't. The Blocked event (when it appears) has a different UID, so a naive tool can't correlate it to the disappeared booking without comparing date ranges.

If your sync tool is polling every 15 minutes and the Vrbo feed hiccups (which it does, often), you'll see a booking disappear for one poll and reappear the next. If the tool immediately deletes the Jobber job on first disappearance, you'll cancel a live turnover. If the tool waits to confirm the deletion, the cancellation detection lags by hours.

Vrbo also rotates UIDs when a guest modifies a booking (changes checkout date, adds an extra night). The old UID disappears; a new UID appears with the updated dates. A tool that treats "UID disappeared" as "booking cancelled" will fire false cancellations on every guest-initiated date change.

Why "just delete missing bookings" overfires

The naive solution is: if a booking UID was in the last poll and it's not in this poll, assume it cancelled and close the Jobber job.

This breaks for three reasons:

1. Vrbo feed transience. Vrbo's iCal feed returns HTTP 200 with a truncated or stale body roughly 2-5% of polls in my observed sample. A booking disappears for one 15-minute window, then reappears. If you delete on first absence, you cancel live jobs.

2. UID rotation on edits. Guest extends checkout by one day. Vrbo issues a new UID. The old UID vanishes. Your tool closes the job. The property owner calls you asking why the turnover got cancelled when the guest is still there.

3. Blocked insertion lag. Vrbo sometimes inserts the Blocked event in the same poll that removes the booking UID; sometimes it takes 1-3 polls. If you're deleting immediately, you can't correlate the Blocked event to the disappeared booking.

The alternative is to wait for multiple consecutive absences before treating it as a cancellation. This reduces false positives but pushes cancellation detection 30-90 minutes later. By then your scheduler has often already dispatched the cleaner.

What good Vrbo cancellation handling needs

A robust approach requires:

1. Blocked-event correlation. When a UID disappears, check if a Blocked event now covers the same date range (within a tolerance of ±1 day, because Vrbo's Blocked events sometimes have fencepost differences). If yes, treat it as a confirmed cancellation immediately.

2. Grace window for transient drops. If a UID disappears and no Blocked event appears, wait for 2-3 consecutive absences (30-45 minutes at 15-minute poll intervals) before treating it as cancelled. This filters transient feed hiccups and UID rotations that resolve quickly.

3. No false "job completed" notification. When you close the Jobber job, remove the visit from the cleaner's schedule in a way that does not fire a "job completed" notification. The cleaner should see the job disappear from their calendar; they should not get a completion ping for work they didn't do.

4. Owner-facing invoice suppression. If the property owner is set up to receive invoices on job completion, the cancelled job should not generate an invoice. This requires modifying the Jobber job's line items in a way that suppresses automatic invoicing without deleting the job record (you want the audit trail).

I can describe what these behaviors look like from the cleaner's perspective; I won't detail the exact Jobber API calls involved (that's CleanSync's competitive mechanism). The point is: if your sync tool doesn't handle all four, you'll either overfire false cancellations or underfire real ones.

How CleanSync handles Vrbo silent cancellations

CleanSync polls every 15 minutes. When a Vrbo booking UID disappears, it checks for a Blocked event covering the same dates. If one exists, it closes the Jobber job immediately, removes the visit from the cleaner's schedule, and suppresses the invoice. The cleaner sees the job vanish; no completion notification fires.

If no Blocked event appears, CleanSync waits for three consecutive absences (45 minutes total) before treating it as cancelled. This grace window filters UID rotations (which resolve in 1-2 polls) and transient feed drops (which resolve in 1 poll) while still catching real cancellations within an hour.

The UID-rotation case (guest extends or shortens the stay) is handled separately. When a new booking appears with dates overlapping a recently-disappeared booking, CleanSync treats it as a modification, not a cancellation. The Jobber job gets updated with the new checkout date and time; the visit on the cleaner's schedule shifts accordingly.

All of this is documented in /docs/cancellations-and-reschedules. The logic runs inside Jobber's infrastructure (CleanSync is a native Jobber App Store integration); there's no third-party middleman holding your booking data.

If you're running Vrbo turnovers through Jobber and your current sync tool is missing silent cancellations, install CleanSync from the Jobber App Store (it's free). The quick-start guide covers the iCal URL hookup; cancellation handling runs automatically once the feed is connected.

If you're evaluating tools and want to compare how Breezeway or Properly handle this pattern, see Breezeway vs CleanSync and Properly vs CleanSync. Both of those posts have sections on cancellation handling. Neither Breezeway nor Properly is a bad product; they're just solving a different problem (property-management platform) than CleanSync (Jobber-native STR automation for cleaning companies that already run scheduling and invoicing through Jobber).