Ticketing hosting sized for the minute tickets go live.
A ticket site sits idle for weeks and then takes a year of traffic in ninety seconds. Only one of those two states is worth engineering for.
Everything a ticket drop asks of a host.
The load is not a high average. It is every buyer arriving in the same second, already signed in and ready to write.
Capacity that arrives before the queue does
Tell us the on-sale timestamp and we scale ahead of it rather than reacting to it, because autoscaling triggered by load is already half a minute late by the time the queue has formed.
One seat, one buyer
Ticket rows are locked at the database rather than checked in application code, so two people clicking the same seat in the same millisecond cannot both be told it is theirs.
A queue instead of a crash
Once concurrency passes what checkout can serve, buyers are held in an ordered waiting room and admitted in turn - slower for them, but nobody is shown an error page.
Bots kept off the allocation
Rate limiting and challenge rules run at the edge before WordPress loads, so scripted buyers do not consume the inventory you meant for real ones.
Holds that expire on time
Abandoned baskets release their seats on a platform timer rather than a visitor-triggered cron, so unsold inventory returns to the pool even at four in the morning.
Watch the drop as it happens.
During an on-sale the only question is whether checkout is keeping up. Numbers gathered afterwards are an autopsy rather than an answer.
- Live concurrency and checkout latency
- Alert before workers saturate
- One-click admin login for the whole team
- Restore any daily backup from the dashboard
Checkout under three thousand concurrent buyers.
Every request in an on-sale is a write, and writes cannot be cached. What decides the outcome is how many of them the database will accept at once.
What we change for a ticketing site
These are the settings that differ from a standard WordPress site on the same plan. Each one exists because demand arrives at a timestamp you already know.
| Setting | What we do | Why |
|---|---|---|
| Capacity | Scaled ahead of an announced on-sale rather than in response to load | Reactive autoscaling begins provisioning after the queue has already formed, which is the wrong half of the minute. |
| Full-page cache | Bypassed on basket, checkout and seat-selection URLs | A cached seat map shows the seats that were free when it was generated, which is precisely how a site oversells. |
| Ticket inventory writes | Row-level locks with a short lock timeout | Two buyers reaching the same seat in the same millisecond must not both receive a confirmation email. |
| Basket expiry | Platform timer, independent of site traffic | Held seats have to return to the pool overnight, when there is nobody on the site to trigger a cron run. |
| Edge rate limiting | Per-IP and per-session challenge rules ahead of PHP | Scripted buyers absorb both allocation and worker capacity that was meant for the queue behind them. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
How do you handle a scheduled on-sale?
Can the site oversell?
Do you support a virtual waiting room?
What stops bots taking the allocation?
Does the site cost the same between events?
Put your next on-sale on a host that was told it was coming.
Free migration, capacity scheduled to the minute, and inventory that cannot be sold twice.