iCal sync delays: the real figures, platform by platform
You have blocked a date on Airbnb and Booking still does not show it. Before you unplug anything, look at the table below: your wait may be perfectly normal. Here are the real rhythms of each platform, and what is at stake during the wait.
By the 1calendrier team · Updated 11/08/2026
The table of delays, platform by platform
Figures gathered in August 2026: the official help pages where they publish a rhythm (Airbnb, Abritel and Vrbo), and measurements shared by owners for the rest (Booking and Google publish nothing). No platform guarantees these rhythms: take them as orders of magnitude. They apply to each listing separately: every calendar link lives at its own pace.
| Platform | Reading rhythm observed | What it means for you |
|---|---|---|
| Booking | of the order of 2 to 3 hours (observed by hosts, not published) | an Airbnb booking takes up to 3 hours to block Booking |
| Airbnb | every 3 hours (figure published by Airbnb) | a Booking reservation takes up to 3 hours to block Airbnb |
| Abritel / Vrbo | every 30 minutes (figure published by the platform) | the best pupil in the family, with no guarantee either |
| Google Calendar | often 8 to 24 hours (no rhythm published by Google) | the slowest personal diary at re-reading a link |
Two points for reading that table properly. First, the delay starts from the reading, not from the booking: if Booking has just read your Airbnb calendar a minute before a new booking, that booking will wait for the next pass. Second, the delays add up when the information crosses an intermediary: a block that goes through a diary re-read every 24 hours before reaching a platform re-read every 3 hours can take more than a day to arrive. That is one of the reasons why set-ups built around Google Calendar freeze so often.
Below 24 hours of waiting, your sync is probably not broken: it is waiting its turn. Beyond 24 hours with no update, look for a real cause: they are listed in why your Airbnb calendar is no longer syncing.
Why these delays exist
A calendar link works like a subscription: the subscribing platform comes back to read the calendar at regular intervals. It receives nothing between two passes. Nobody tells it that a booking has just come in; it finds out at its next reading.
Why not read every minute? The question of scale is answer enough. Each platform re-reads millions of calendar links, for listings that, most of the time, have not changed since the day before. Re-reading every calendar every minute would multiply the load a hundredfold for a tiny gain. Platforms have therefore chosen a compromise: a rhythm of a few hours, enough for a letting schedule, not enough to prevent two almost simultaneous bookings. That compromise is structural. It cannot be got round, it has to be managed.
That is also why the rhythms vary. In high season, when the servers take the most bookings, owners observe readings further apart than usual. A 3-hour cycle that stretches to 5 hours on an August Saturday is nothing out of the ordinary.
Can a re-reading be forced?
Sometimes, a little. Here is what works and what does not, observed in August 2026.
On Airbnb, an imported calendar comes with a manual sync option: open "Connect calendars", and trigger the update of the calendar concerned. Airbnb then re-reads the link without waiting for the next cycle. The platform does warn, however, that it limits the number of requests made close together: beyond that, you have to wait for the next automatic update.
On Booking, the "Sync calendars" section of the extranet also offers a manual refresh of imported calendars ("Import now"). It restarts the reading of the links Booking imports; it does not, on the other hand, speed up the reading of your Booking calendar by the other platforms.
The last-chance move, quoted on every forum: delete the imported calendar and paste the link back. Most platforms read a freshly pasted link within minutes. It works, but keep it for genuine emergencies, for example a direct guest paying a deposit and dates to be blocked everywhere as quickly as possible. As a daily habit, it is no way to work.
What is of no use at all: refreshing the page frantically, unplugging and plugging back in several times a day, or copying the dates by hand on top of the sync (you create duplicate blocks that you will have to untangle later). After each booking, there is nothing for you to do: the information will travel at the next cycle.
Living with the delays: the right habits
Since these rhythms cannot be negotiated, you may as well organise your habits around them. Three habits are enough.
Before confirming a direct guest, wait until you have blocked everywhere. A deposit taken over the telephone blocks nothing anywhere. Close the dates on your main calendar first, let a full reading cycle pass, check that the block has arrived on each platform, and confirm after that. A few hours of patience against weeks of trouble.
Never conclude that something is broken before 24 hours. Half the "broken syncs" reported on forums are normal waits. Unplugging and redoing everything after two hours repairs nothing and sometimes loses the history of the connection.
Note your real delays. At each test or block, note the departure time and the arrival time opposite. After a few weeks, you will know the real rhythm of your platforms, often steadier than the general ranges. That notebook will tell you at a glance whether a wait is normal or worrying, and it will serve as evidence on the day you have to show that your set-up was working.
And if somebody books during the window?
That is the real question behind every forum thread about delays. A booking comes in on Airbnb at 2 p.m. Booking will only re-read your calendar at 4.30 p.m. In between, Booking is selling dates it believes are free. If a guest takes them at 3.45 p.m., you have a double booking, even though your set-up is working perfectly.
Let us be direct: that risk cannot be removed. Not with free iCal, not with a paid system, and not with us. As long as two platforms sell the same property, there is a window during which they can sell it twice. Anyone who promises you no risk at all is describing a product that does not exist.
What is really at stake is the time that passes between the overlap and the moment you learn of it. Discovered within the hour, an overlap is settled with a telephone call to a guest who has just booked and has organised nothing yet. Discovered three weeks later, on the eve of the arrival, it becomes a painful cancellation, with penalties and a disappointed family. The overlap itself is visible in the calendars as soon as it exists: somebody still has to look. A monitoring service reads your calendar links every 30 minutes (every 15 minutes on the Pro plan), spots overlapping bookings as soon as they appear and alerts you at once. It speeds up no platform; it shortens your reaction time, which is the only variable anybody has a hold on. The other safeguards, a buffer day or manually approving requests, combine with monitoring and are compared in how to avoid double bookings.
To place your own set-up against these figures, measure it: the test-date method, stopwatch in hand, is described in how to check that your calendars really are in sync. And if you are connecting your platforms for the first time, follow the guide on syncing Airbnb and Booking.
Frequently asked questions
Is the delay the same for a cancellation?
Yes. A cancellation travels like a booking: it only appears opposite at the next reading of the link. The freed dates may therefore stay blocked for a few hours on the other platforms, and a block sometimes takes a full cycle to disappear.
Does the first reading after connecting follow the same delays?
No, it is usually quicker: most platforms read the link within minutes of it being pasted, to show you that the connection has taken. The cruising rhythm settles in afterwards. So do not draw any conclusion about future speed from that first reading.
Does a channel manager remove these delays?
In part. A system connected directly to the platforms exchanges faster than a calendar link. But no tool removes every delay, and the window of risk exists with them too, in a shorter form. Be wary of promises of 'real time' with no figures.
Can these figures change?
Yes. They are rhythms observed in August 2026, not commitments by the platforms. They adjust them without warning, and the load on their servers makes them vary from one day to the next. Take them as reliable orders of magnitude, not as train timetables.