// INSIGHTS
The rehearsal protocol: testing a venue before show day
6 min read
A rehearsal is not a walkthrough with a clipboard. It is a set of tests with pass criteria, measured timings and a named person who can call a rollback. We rehearse venue networks, kiosks, signage and offline-first systems the same way: build it, break it deliberately, measure the recovery, sign it off. The fortnight before doors open decides almost everything that happens after. Here is how we spend it.
Rehearsal is engineering, not theatre
Every test needs a number attached. "The wifi works" is not a result. "2,400 associated clients across 34 access points, median download 18 Mbps, 95th percentile association under 3 seconds" is a result. We write pass criteria before the test runs, so nobody negotiates the standard downward at 23:00 on build night.
Order matters. An RF survey before build shows the venue's own noise floor: house wifi, the neighbouring hall, radio mics, the switching supplies behind an LED wall. A second survey after the rig is up shows what our own structures did to it. Truss, tenting, metal partitions and a full room of bodies each cost signal, and coverage measured in an empty hall is optimistic by a wide margin.
Then we rehearse failure. A system that has never been broken in front of the people who operate it is not tested. It is only untried, which is a different and more expensive condition.
T-14 to T-0 in numbers
The drills that matter
Kill the WAN
We physically pull the primary uplink mid-session and watch the bonded backup carry the load. LAN-origin QR codes and local DNS mean check-in, signage and kiosks keep resolving with no WAN at all.
Kill the database, bucket and deployment
For offline-first PWA builds we switch off the database, the object storage bucket and the entire cloud deployment, then use the app. Content packages bundled into the build keep it running; if it stops, it was never offline-first.
Load test with simulated clients
We generate association and traffic load at the target client count before real people arrive. Controllers, DHCP scopes and captive portals fail differently at 400 clients than they do at 40.
DG changeover under load
We drop mains with the full rig running and time the ATS gap against the UPS bridge. A generator that starts cleanly in an empty hall proves very little about show day.
Gates and sign-off
T-14: plan frozen
Test list, pass criteria, runbook draft and rollback authority are agreed in writing. Content freeze dates for signage and kiosks are set on the same day.
T-5 to T-3: build and instrument
Network, kiosks and signage go in. Pre-build and post-build RF surveys are compared, and AP power, channel plan and mounting heights are adjusted against the difference.
T-2: drills day
WAN kill, cloud kill, DG changeover, failover timing and load test run in sequence. Each result is logged against its pass criterion, with a re-test slot the same evening.
T-1: dress rehearsal
Real content, real operators, real handsets, walk tests across the actual floor plan. Punch list closed, comms check completed, runbook signed, known-good release hash written on it.
What usually goes wrong
Content arrives after the freeze. The signage playlist and the kiosk copy get replaced at 21:00 on T-1, which means the version that was tested is not the version that runs. We handle this with immutable hashed releases: every build carries an identity, the last known-good hash is printed on the runbook, and rollback is one action instead of a debugging session. The tradeoff is discipline. Someone has to refuse an untested change at 02:00, and that person needs authority agreed in writing two weeks earlier.
The other common failure is rehearsing the wrong thing. Teams test the demo path and skip the ugly ones: a delegate whose phone is at 4 percent with aggressive power saving, a kiosk scanner in direct sun at 45C, a hall that fills in eleven minutes rather than forty. There are also honest limits. We cannot simulate 2,000 human bodies absorbing signal, we cannot know the crowd's real device mix, and we cannot test what the venue's house network decides to do on show morning. What we can do is leave headroom, staff the on-site IT desk, and make sure every failure mode has a rehearsed recovery with a measured time.
Common questions
How long does a proper rehearsal need?
For a mid-size conference we ask for planning from T-14 days and a minimum of two full days on site: one drills day and one dress rehearsal. Compressing it into a single evening is possible, but you lose the load test and the DG changeover test, which are the two that catch the expensive failures. When the schedule forces that, we say so in writing before the build.
Who is allowed to call a rollback during a live session?
Two named people, agreed at T-14 and printed in the runbook, usually our on-site lead and one client-side owner. Anyone can report a fault, but only those two can trigger a rollback to the known-good hash. This prevents the situation where four people debate options while the screen stays blank.
Can you rehearse an offline-first system without the venue?
Partly. We can switch off the database, the bucket and the whole cloud deployment in our own environment and prove the application still runs from its bundled content package, and that is a genuine test. What cannot be rehearsed off site is the venue RF environment, real crowd density or house electrical behaviour. An on-site rehearsal window is still required.
Rehearse it before the room fills
Send us the floor plan and the run of show, and we will return a rehearsal timeline with pass criteria and sign-off gates.
