When a highly anticipated event opens, hundreds of attendees rush to book limited hotel room blocks or pick assigned seating at the same time.
Availability starts to fluctuate, and attendees can't tell why. The numbers are correct, but they shift fast: attendees grab whatever is open to secure something, switch to their first choice if it frees up, and churn through reservations. Each selected item is held while they check out, so it looks taken to everyone else. With hundreds doing this at once, availability keeps moving, which drives panic and more grabbing.
Here is how that plays out, and how Eventact's Registration Queue turns a registration rush into a more controlled booking experience.
How the Queue Works
Eventact lets organizers cap how many people can be registering in a form at the same time. The cap is set per form.
While the number of people inside the form is below the cap, visitors go straight in as usual. Once the cap is reached, new visitors are placed in a queue. Each time someone submits or leaves the form, a place opens, and the next person in the queue is let in automatically to start their registration.
Because only a limited number of people are choosing rooms and seats at any moment, fewer items are on hold at once, and what attendees see as available stays much steadier.
What the Cap Actually Limits
It limits how many people are inside the form at the same moment. That is the whole of it, and it is worth being precise, because it is easy to read it as one of two things it is not.
| The cap controls | The cap does not control |
|---|---|
| People inside the form at the same time | Total registrations |
| Concurrent registration activity | Event capacity |
| Load on scarce inventory | How many tickets, rooms, or seats can ultimately be sold |
A form capped at 100 can still take 5,000 registrations over the day. It just takes them 100 at a time. If you want to stop at a certain number of registrations, that is the event's capacity and quota settings, not this.
The cap is set per form, not per event. Two forms on the same event have separate caps and separate queues, and a visitor's place in one has nothing to do with the other.
Turning It On
One field, in the form builder:
- Open the registration form and go to its settings.
- Expand Login Options.
- Find Maximum visitors at the same time (0 = unlimited).
- Type a number and save.
That is the entire setup. Nothing else needs to be switched on, no queue needs configuring, and no separate page needs designing.
Every form starts at 0 (unlimited) and behaves exactly as forms always have. Nothing about your existing forms changes until you deliberately put a number in this field, and setting it back to 0 turns the queue off again.
The change takes effect on the next visitor — there is no publish step and no cache to wait out. That means you can raise the cap in the middle of an opening rush and the extra places open immediately.
What a Waiting Visitor Sees
Someone who arrives when the form is full lands on a wait page carrying the event's theme — the same colors, logo, and styling as the form itself — which tells them:
The registration form is busy.
You are in the queue. Please keep this page open — it will take you to the form automatically as soon as a place opens.
About 12 people are ahead of you.
The page is translated into the same languages as the registration form and automatically detects the visitor's language.
The "people ahead of you" figure updates itself every few seconds and only ever counts down, so the wait visibly shortens. It is deliberately approximate — hence "about" — because it counts places rather than tracking individuals, and it can slightly overstate when people who took a number have wandered off.
The important part is that the visitor does nothing. They don't refresh, re-click the link, or watch for their turn. The page checks every ten seconds or so on its own and moves them into the form the instant a place is theirs. The one thing they must do is leave the tab open.
How Places Free Up
A place is held from the moment someone enters the form until one of these happens:
| What happens | When the place frees |
|---|---|
| They submit the registration | Immediately |
| The form closes on them with an error or a closed notice | Immediately |
| They close the tab, or simply stop | After about six minutes of no activity |
The six-minute idle timeout is what keeps abandoned sessions from silently eating your cap all day. It is fixed and not configurable, and it is measured from a visitor's last activity, not from when they arrived — someone genuinely working through a long form keeps their place indefinitely.
Registrants Are Never Sent Back to the Queue
This is the rule worth knowing because it protects your registrants. The cap is checked only at the front door. Once a visitor is inside, they are never bounced out:
- Every page and step of the form passes straight through, even while a queue is waiting outside.
- Someone returning from a payment gateway always lands on their confirmation, never on the wait page.
What You Can See, Live
The registration dashboard page in the back office shows:
- In form now — how many visitors hold a place right now, shown against the cap, for example 87 / 100.
- Waiting — how many people are sitting on the queue page.
What you do with those two numbers:
| What you see | What it means | What to do |
|---|---|---|
| In form well under the cap, nothing waiting | The cap is not biting | Nothing |
| In form at the cap, a handful waiting | Working as intended, waits of seconds | Nothing |
| In form at the cap, hundreds waiting and holding | More demand than the cap is clearing | Raise the cap, then watch how availability behaves |
| Waiting high while In form sits below the cap | Unusual — worth a look | Usually clears within a poll cycle; contact support if it persists |
Raising or lowering the cap takes effect immediately, so this is a dial you can turn during the rush itself, not a setting you have to get right in advance.
Choosing a Starting Cap
Start conservatively. A cap that is too high lets too many attendees compete for the same limited inventory at once. A cap that is too low causes some extra waiting, but you can raise it during registration.
Here is a practical way to choose a starting point:
- Most events need no cap at all. If your event does not have scarce assigned seating, limited hotel room blocks, or other inventory that is likely to sell out very quickly, leave the cap at 0 (unlimited).
- Start at 30%–50% of the scarce inventory. If you expect any bookable item to run out within 30 minutes of registration opening, let roughly a third to a half of that item's quantity into the form at once. For 200 hotel rooms expected to go within 30 minutes, start with a cap of 60–100.
- Factor in how long registration takes. The longer attendees stay in the form, the lower the cap should be. For a multi-page form with extra selections or payment authentication, start near 30%. For a short form, start near 50%.
- Adjust as you go. Watch the In form now and Waiting tiles in the first few minutes. If the queue moves smoothly and availability stays stable, gradually raise the cap. Changes apply to the next visitor.
- Don't go below what the inventory justifies. A cap of 5 or 10 fits only when a handful of scarce items are available. On a larger launch, it creates waiting with no benefit.
- Test before opening registration. Set the cap to 2 on a test form and open three separate browser sessions. The first two should enter the form, while the third should remain on the waiting page until a place becomes available.
Limits and Things to Know
- Queue order is approximate, not guaranteed. Near the front, people may go in slightly out of turn.
- A queue place belongs to the browser session. If the same person opens the form on both a phone and a laptop, each device gets its own place in the queue.
- Closed forms remain closed. Nobody is queued for a closed form.
- The cap applies to individual forms, not the form-selection page. The cap applies once a visitor picks a form.
- Queue-page wording is currently fixed. It is translated but can't be edited.
- Waiting visitors are not yet registrants. They hold no inventory. The Waiting tile is their only sign.