Availability
Pass, Event, and session capacity, the 15-minute hold, and what a buyer sees when a Pass sells out
Capacity is what stops you overselling. It is counted separately at three levels — the Pass, the Event, and each session — and reserved only when a buyer starts checkout, never while they browse.
If you have ever sold 201 seats for a 200-seat room, this page is the answer to how that does and does not happen here.
Levels
Pass, Event, session
Each is an independent ceiling
Reserved when
Checkout starts
Browsing reserves nothing
Hold length
15 minutes
Fixed at intent; nobody can extend it
Released when
Expiry, failure, or Event cancellation
A worker sweeps expired holds every minute
Consumed when
Payment confirms
Held seats become sold seats
Counted from
Confirmed entries plus live holds
Not a stored counter
Three ceilings, one number each
| Capacity | Who sets it | What it counts |
|---|---|---|
| Pass capacity | The Pass | Entries, or people, per the Pass's capacity basis |
| Event capacity | The Event | People, across every Pass |
| Session capacity | Each Event session | People, for Passes that include the session |
A Pass capacity is the main limit on a tier. Event and session capacities are optional ceilings above it, which is how you cap a room without capping a tier.
The Pass's capacity basis decides what one place means:
- Registrations — one place per entry, so a five-person team uses one place.
- Participants — one place per person, so the same team uses five.
Event and session capacity always count people, whatever the Pass says. A team of five is one Pass place under a registrations basis and five people against the room.
Where the number comes from
Nothing stores "seats remaining". Every check adds two things up:
A hold counts only while it is active and unexpired. A confirmed entry counts until its Registration is cancelled.
That has two useful consequences. A cancelled Registration stops counting, so its place becomes sellable again without any manual step. And an abandoned checkout stops counting the moment its hold expires, even if the buyer never returns.
Nothing else counts. A draft Registration, a pending Approval, and an abandoned browser tab all reserve nothing.
The 15-minute hold
An InventoryHold is created inside the same database transaction as the pending Order, so a double-click cannot produce two Orders or two holds.
T+0The buyer starts paying
The Order is created as payment pending, and one hold per line reserves Pass, Event, and session capacity at once.
T+0 to T+15The seats are reserved
The payer sees a countdown. Reloading the page reopens the same provider order and the same hold; it does not restart the clock.
T+15The hold expires, if unpaid
A worker releases expired holds about once a minute, and the next capacity check ignores them immediately, even before the worker runs.
on successThe hold becomes a sale
Confirmation flips the hold to consumed and the entries to confirmed, in one transaction.
A hold ends early in two cases: the provider order cannot be created at all, and the Event is cancelled. A declined card is not one of them — the Order stays pending so the buyer can retry, and the hold runs its full 15 minutes.
A workable example
A 500-seat room, a Day Pass capped at 200 places counted per person, and 137 confirmed entries in the Pass. Two buyers are paying, holding 3 and 2 places.
Confirmed entries
137 places
Live holds
3 places and 2 places, both unexpired
+5 places
Used against the Pass
142 places
Remaining in the Pass
58 places
Holds here are 5 places in total. The room holds 500 and has 341 people confirmed plus those same 5 held, so the Pass limit binds first.
A buyer asking for 3 places succeeds. A buyer asking for 60 fails, even though each of the sixty would have been individually available — the check is on the whole request.
Whichever ceiling is closest binds first. With 346 people already used against the room, the room would stop a sale before the Pass if it had fewer than 58 places free.
Quantity limits per Order
A Pass can require a minimum and allow a maximum quantity per Order, from 1 to 50. The count is per Pass, across all the lines a buyer checks out together.
| Setting | What it does |
|---|---|
| Minimum 2 | One entry alone cannot be bought |
| Maximum 4 | Five entries in one checkout are refused |
| Maximum 1 | One checkout, one place — the usual setting for gated Passes |
A team entry counts as one unit of quantity regardless of its roster size.
When a Pass is sold out
There is no stored "sold out" state, and no seat counter on the public Event page today. The check happens when a buyer starts paying, and a full Pass produces a conflict error rather than a queue.
That has one visible consequence: the pay button works until it doesn't. A buyer who reaches checkout on a full Pass is told the Pass is unavailable and can try another Pass, rather than being placed in a line.
Waiting rooms, ordered sale queues, and waitlists are not available in the product. There is also no scheduled "drop" of returned capacity; when a place frees up it is simply sellable to the next buyer.
Failure paths
| What happens | What the buyer sees |
|---|---|
| Capacity ran out between browsing and paying | Checkout refuses; nothing is charged |
| The card is declined | The Order stays pending until the window closes, so the buyer can retry |
| The hold expired while paying | The Order expires and the entries unlink; a fresh checkout is needed |
| The provider order cannot be created | The Order is cancelled, the hold released, and the entries unlink |
| The Event's sales are paused | Every new checkout refuses until sales resume |
| The Pass is switched off | The Pass disappears from the public page and checkout refuses |
| The Event is cancelled | Pending checkouts are cancelled and their holds released |
Related
- Passes — capacity as one Pass setting
- Checkout — where the hold is created
- Payments — what confirmation does with a hold
- Registrations — what a confirmed entry is