Live Availability & Online Booking

What determines an open slot

Your public booking page doesn't work from a fixed schedule template. Every time it loads, it computes availability from three live inputs: your working hours, any time you've blocked out, and the bookings that already exist. Change your hours for a day, block out an afternoon, or take a new booking, and the next person who opens the page sees the result immediately.

This is the same calculation whether the page is being viewed at 9am on a Tuesday or 11pm on a Saturday. There's no separate cache of available times that gets refreshed on a schedule and can drift out of date between refreshes. Availability is always a live answer, not a stored one.

Checked twice: once to show it, once to confirm it

What a customer sees when the page loads is a snapshot. Between that moment and the moment they hit confirm, someone else could be looking at the same slot, or a booking could come in through another channel. So the slot they picked gets checked again, right before it's confirmed, against the same three inputs.

That second check is not a courtesy check in the interface that a slow connection or an open second tab can slip past. It's enforced as an exclusion constraint at the database level, meaning the database itself refuses to store two overlapping bookings for the same resource and time, no matter which path the request came through or how many arrived at once.

• Two customers with the same page open at once
• A booking that comes in while another is mid-confirmation
• A retried request after a dropped connection

In all three cases, only one booking can ever be written for that slot. The other is rejected, not silently allowed to overlap.

For restaurants and venues, it's tables and floor, not just time

For hospitality businesses, the same mechanic that computes appointment availability computes table and floor availability instead. An open slot isn't just a free half hour, it's a free half hour with an actual table behind it. The same three inputs, hours, blocked time and existing bookings, determine what's genuinely open on the floor at that moment.

The same re-check at confirmation applies here too. A table that looks free when a guest starts booking is checked again before the reservation is confirmed, using the same database-level guarantee that prevents two appointments from double-booking a provider.

Why the guarantee matters

Booking systems that only check availability in the interface tend to fail in one specific, expensive way: under real concurrent load, two people checking the same nearly-full calendar at once, or a booking landing at the same moment another is being confirmed. Interface-level checks can miss that moment. A database-level exclusion constraint can't, because the guarantee lives at the layer that actually stores the booking, not the layer that asks for it.

For you, this means the availability shown to a customer is trustworthy without needing a manual double check before you rely on it. The same live calculation and the same confirmation-time guarantee apply no matter how many people are looking at the calendar, or trying to book, at the same time.