Sync Latency: What 60 Seconds Costs Across Four Channels

Polling and push are not the same promise. The gap between them is where a double booking is born.

Last updated: November 1, 2026

A calendar can learn about a new booking in two ways. It can ask the channel on a timer, or the channel can tell it the moment something changes. The first method leaves a gap that lasts until the next question, and the second leaves a gap measured in delivery. A double booking lives in whichever gap you have.

Key Takeaways

• Two methods, two different promises. Polling promises an answer eventually. Push promises a message when something happens. Neither promises instant.
• The gap is a window, not a number. It opens when a guest books and closes when your calendar knows, and its width changes with load and with the channel.
• Both directions matter. A booking coming in late and a block going out late produce the same result: a night that's sold twice.
• One double booking costs more than the refund. Rehousing, the review, the buffer you add afterwards, and the month you spend not trusting the calendar.
• Measure your own gap. Time it on your own listings, on a normal evening, twice. That number is the only one worth planning around.

Two ways a calendar learns about a booking

The first method is polling, and it works the way it sounds. Your software asks the channel whether anything has changed, gets an answer, waits, and asks again. Between two questions, your calendar is working from an old answer, and that's not a bug. It's how the method works.

The second method is push, and it inverts the direction. The channel tells your software that something changed, when it changes. The gap shrinks to the time it takes to deliver the message and process it, but it doesn't disappear, because delivery isn't instant either, and because the receiving end has to do something with what it just heard.

Neither method is dishonest. Each makes a different promise, and the trouble starts when a host reads one promise and plans against the other. If you assume your calendar always knows, and the connection is polling, you'll eventually be wrong at the worst possible moment.

There's a third thing worth knowing, and it's where most of the confusion sits. A connection can be event-driven for availability and timer-based for rates, or the reverse. A rate that lands late is annoying. An availability update that lands late is a booking you can't honour.

Where the gap opens

Take a gap of 60 seconds, purely as an illustration, because it's the kind of number that sounds small enough to ignore. Now put a booking inside it.

A guest books your Friday night at 21:14. The booking exists on that channel immediately. Your calendar hasn't heard yet, because the question hasn't been asked or the message hasn't arrived. At 21:15, a second guest books the same night on a different channel, which is reading the same stale answer. Both bookings are valid. Both guests have a confirmation. Neither has done anything wrong.

That's the whole mechanism, and it has nothing to do with four channels or with any particular platform. Two channels, one calendar, one window.

The window isn't a fixed width either. It changes with how busy the channel is, how busy your software is, whether the connection is healthy, and whether a rate push and an availability push travel on the same path. A gap you measured at 2am on a Tuesday isn't the gap you'll get at 9pm on a Friday in July, which is exactly when you needed the answer.

There's a second window in the other direction, and it's the one hosts forget. You block a night, or change a rate, and the change has to reach the channel. Until it does, the channel is still selling what you've already decided to stop selling. A booking that arrives in that window is just as real as the first one, and just as much your problem.

So the honest description of a connected calendar is this. It narrows the window. It doesn't close it, and nothing you can buy closes it, because the window is a property of two systems communicating, not of one system being good.

What one double booking costs

The refund is the part everyone counts, and it's usually the smallest part.

Start with the guest who has nowhere to sleep. You either rehouse them, at your cost, in a city where the nearest available bed might be a suburb away, or you cancel and they find out at the door. The first costs money and a favour. The second costs a review that sits at the top of your listing for a year.

Then count your own afternoon. Calls, messages, a refund, an apology, a conversation with the other guest about whether they'd move. That's the part nobody prices, and it's the part that repeats, because after the first one you'll start padding.

The padding is the expensive sequel. A host who's been burned once starts blocking a buffer night on either side of every booking, and buffers cost occupancy every week of the year to protect against an event that happens twice. That's a real trade, and it's worth making deliberately rather than as a reflex.

There's a fourth cost that's harder to see. You stop trusting the calendar, and once you stop trusting it, you start checking four dashboards by hand every evening. That's the exact job the software was supposed to remove, and it comes back on the days you're busiest.

Checking your own account

You can't fix a gap you haven't measured, and you don't need anyone's published number to measure your own. Do it on a normal evening, on your own listings.

Open the channel detail view and look at what it reports for each connected platform: which channel is connected, what its last sync state was, and whether the last push carried a rate, availability, or both. localsbnb.com shows each channel's own rate and status beside the night it applies to, across Airbnb, Booking.com, Agoda and Trip.com on one calendar, which is what lets you see a stale night rather than guess at one.

Then run a controlled test. Block a night in your calendar, note the time to the minute, and watch how long it takes to disappear from each channel. Repeat it once at a quiet hour and once at a busy one. The difference between those two measurements is more useful than any average, because your problem will arrive during the busy one.

Then do the harder test, the one that matters. Make a real booking on one channel, at a time you choose, and note when it appears on the others. You'll learn two things: the width of your gap, and whether it's stable. If it's stable, you can plan around it. If it's erratic, you have a connection problem rather than a latency problem, and those are different jobs.

Write both numbers down, with the date and the hour. Then decide what to do with them: a buffer on the highest-risk nights, fewer channels on the unit with the tightest turnover, or a manual check at the hour your bookings actually arrive.

FAQ

Is 60 seconds the real sync time?

It's an illustration, not a specification, and no honest answer exists without naming a channel, a direction and an hour of the day. What matters isn't the number, it's the shape: polling leaves a gap that lasts until the next question, push leaves a gap that lasts until delivery. Time yours and you'll have a figure that applies to your account.

Can a connected calendar still double book?

Yes, and any product that says otherwise is describing a promise no connection can keep. Two systems talking to each other always have a window. What a good setup does is narrow the window, show you when a channel last synced, and make the failure visible early enough to fix it cheaply.

Does adding a fourth channel make it worse?

It makes the window matter more, not wider. With one channel there's nothing to conflict with. With four, every night has three extra chances to be sold twice, so the same gap produces more collisions. That's an argument for measuring the gap before you add the channel, not after.

One window, measured twice, on the nights you actually sell. localsbnb.com puts Airbnb, Booking.com, Agoda and Trip.com on one calendar, with each channel's status beside the night. That makes the gap something you can see, rather than something you hear about from a guest at the door.

---

This article is general guidance for hosts and isn't legal, tax or insurance advice. Sync behaviour, connection health and each platform's API terms change without much notice, so confirm current behaviour with the platform and with your software provider before you rely on any timing assumption.