In conference technology, a technical dry run is the structured, end-to-end walkthrough of every system, signal path, and human handoff that will carry content during a live event. It is not a rehearsal of the content itself. It is a stress test of the infrastructure: the encoders, the network topology, the backup power, the comms loops, the slide advance protocols, the stream-switching logic, and the dozen other failure points that turn a polished keynote into dead air. Adjacent concepts include the tabletop exercise (a discussion-based walkthrough of failure scenarios), the integration test (verifying that two systems actually talk to each other), and the load test (pushing bandwidth or concurrent users to breaking point). For the audience that builds and operates hybrid and virtual events, the dry run is the single highest-return activity separating a known-good signal chain from a prayer. Yet most dry runs are run so poorly they create false confidence. This article is about fixing that.
Why Most Dry Runs Are a Waste of Time
The typical dry run for a virtual or hybrid event follows a script that is too polite to be useful. A producer cues a speaker, the speaker shares a slide, someone in the backchannel types “looks good,” and the test is declared complete. The problem is not that people are lazy. The problem is that the dry run is treated as a confirmation exercise rather than a failure-hunting expedition. When the goal is to confirm that everything works, the team will unconsciously avoid the edge cases that break things. They will not unplug the backup encoder mid-stream. They will not simulate a 40% packet loss on the venue’s primary ISP. They will not force the remote presenter to join from a phone hotspot in a concrete stairwell. And so the dry run passes, and the live event fails in ways that were entirely predictable.
This pattern is so common that it has a name among broadcast engineers: the green-light bias. Teams want the test to pass because a failed test means more work, a delayed schedule, or an uncomfortable conversation with a stakeholder. The fix is to redesign the dry run so that its explicit purpose is to break things. If you do not find at least three meaningful failures during a dry run, you did not look hard enough.
What a Technical Dry Run Actually Tests
A useful dry run does not test whether the presenter can share their screen. It tests whether the signal chain survives when they inevitably do something unexpected. The scope must cover the full content-delivery path, from the microphone capsule to the attendee’s headphones, and every hop in between. That means testing not just the primary path but the failover paths, the monitoring paths, and the communication paths that let your team coordinate when the primary path dies.
Signal Chain Integrity
Every piece of content at an event travels through a chain of devices, software, and network segments. A dry run must verify that each link in that chain passes content without unacceptable degradation. For video, this means checking colour fidelity, frame rate consistency, and lip-sync across every hop: the capture card, the encoding software, the ingress server, the transcoding pipeline, the CDN edge, and the player on a representative device. For audio, it means checking for clipping, ground-loop hum, compression artefacts, and the delay between in-room sound and the stream. One common failure: a venue’s house audio feed sounds fine in the room but arrives at the encoder 200 ms ahead of the video because the audio embedder adds latency that the video path does not. You will not catch this unless you measure it.
Network Resilience
Venue networks are hostile environments. The Wi-Fi that worked perfectly during setup will be crushed by 800 attendees uploading selfies. The wired connection that tested at 900 Mbps will drop to 12 Mbps when the exhibition hall opens and someone plugs in a misconfigured switch that floods the VLAN with multicast traffic. A proper dry run includes active network impairment: throttle bandwidth, introduce jitter, block specific ports, and simulate the failover from primary to secondary ISP. If your streaming encoder does not gracefully handle a 15-second network blackout and resume without operator intervention, you need to know that before the keynote, not during it.
Human Handoff Points
Most catastrophic failures happen at the boundaries between teams. The AV company hands audio to the streaming engineer, who hands it to the remote platform, which hands it to the attendee’s browser. Each handoff is a place where assumptions diverge. The AV team assumes the streaming engineer wants a stereo mix at -12 dBFS. The streaming engineer assumes the feed is already limited to -2 dBTP. The platform assumes the incoming stream is 1080p29.97, but the encoder is set to 1080p30. These mismatches are invisible during a slide-advance test. They become visible when the platform’s ingest server drops the stream because the frame rate doesn’t match the channel configuration. A dry run must explicitly walk through each handoff, with each party confirming the actual signal characteristics, not the documented ones.
Designing a Dry Run That Surfaces Real Problems
The structure of the dry run determines whether it finds failures or hides them. A well-designed dry run is not a linear walkthrough of the run-of-show. It is a series of targeted experiments, each designed to stress a specific component or interface. The following framework has been refined across dozens of hybrid events, from 200-person medical congresses to 20,000-attendee virtual keynotes.
1. Start with a Written Test Plan, Not a Run-of-Show
A run-of-show is a sequence of content moments. A test plan is a sequence of failure scenarios. The test plan should list, for each system, the expected behaviour, the failure mode you want to provoke, the method for provoking it, the expected recovery behaviour, and the actual result. This document becomes the single source of truth during the dry run and prevents the team from skipping uncomfortable tests. It also serves as an audit trail when something breaks live and someone asks, “Did we test this?”
For example, a test plan entry for the primary encoder might read: “Expected behaviour: encoder outputs a 1080p29.97 H.264 stream at 6 Mbps to the primary ingest URL. Failure mode: network interruption of 30 seconds. Method: unplug Ethernet cable from encoder. Expected recovery: encoder reconnects automatically within 10 seconds of cable reconnection, stream resumes without operator intervention. Actual result: [to be filled].”
2. Run the Dry Run in the Actual Venue, on the Actual Network
Testing from a hotel room the night before the event, using a different switch and a different internet connection, is not a dry run. It is a rehearsal of a different event. The physical environment matters: the temperature in the rack room, the quality of the cabling, the RF noise floor, the DHCP lease times configured by the venue’s IT contractor. If the event is hybrid, the dry run must include the in-room AV system, the streaming encoders, and at least one representative remote speaker joining from outside the venue network. I have seen events where the venue’s firewall blocked STUN traffic, breaking WebRTC connections for remote presenters, but only on the guest VLAN. The production VLAN worked fine. The only way to catch that is to test from the actual network that remote presenters will traverse.
3. Test Under Load, Not in Isolation
A single encoder streaming to an empty platform is not a meaningful test. The platform’s ingest servers behave differently when they are processing 50 concurrent streams. The venue’s upstream bandwidth behaves differently when 200 staff members are on a Zoom call. If possible, simulate production load during the dry run. If that is not feasible, at least test during a time when the network is under typical event-day load, such as during exhibitor move-in when dozens of contractors are online. Better yet, run a dedicated load test: saturate the venue’s internet connection with synthetic traffic while monitoring stream health metrics like bitrate stability, frame drops, and round-trip time.
4. Include the Full Tech Stack, Not Just the Streaming Kit
A conference stream is the output of a complex system that includes presentation management software, slide decks with embedded video, wireless presentation links, captioning pipelines, and interpretation relays. Each of these can fail in ways that break the stream. During a dry run, advance slides from the actual presenter laptop, not a clean test machine. Play the embedded video files that will be used in the live session, not a placeholder. Trigger the lower-thirds and transitions from the same graphics operator who will work the show. If the event includes a hybrid component with a room-to-chat handoff, test the full path from the in-room microphone to the remote attendee’s browser, including any moderation or Q&A tools.
5. Break Things on Purpose
This is the part that makes people uncomfortable. A dry run that does not intentionally break things is a rehearsal, not a test. The test plan should include a list of induced failures: pull a network cable, kill a power supply, crash the streaming software, mute the wrong audio bus, send a 4K signal to a 1080p input, join the platform from a browser that is three versions out of date. Each failure should be documented with the expected recovery procedure and the actual outcome. If the recovery procedure does not work, the team now has a known issue to fix or mitigate before the event. If the recovery procedure does work, the team has evidence that their redundancy plan is valid, not just theoretical.
One of the most valuable failure tests is the encoder swap. In a redundant setup, the primary and backup encoders should be hot-swappable. During the dry run, kill the primary encoder and measure how long it takes for the backup to take over. If the answer is more than five seconds, you have a problem. If the backup encoder is not configured with the same scene settings as the primary, you have a bigger problem. I have seen backup encoders that were left in a default scene called “Test” that displayed a giant logo over the presenter. The backup worked, technically. The event did not.
Who Needs to Be in the Room
A dry run is not a spectator sport. Every person who will touch a system during the live event must be present and actively participating. This includes the streaming engineer, the AV lead, the show caller, the presentation technician, the remote speaker wrangler, and the platform administrator. If the event involves interpretation, the interpretation technician must be there. If there is a dedicated network engineer, they must be there. The goal is to surface every assumption each role is making about how the other roles operate. These assumptions are the root cause of most failures.
One role that is often excluded but should be present is the designated breaker. This is a person whose sole job during the dry run is to introduce failures without warning the rest of the team. The breaker might unplug a cable, change a setting, or send a malformed command. The team’s job is to detect the failure, diagnose it, and recover. This simulates the reality of live events, where failures do not announce themselves. The breaker should be someone with enough technical knowledge to introduce realistic failures but enough discipline not to hint at what they did. After each induced failure, the team debriefs: what was the first symptom, how long did it take to notice, was the recovery procedure correct, and what would have happened if this occurred during a keynote.
Documenting the Dry Run: The Difference Between a Finding and a Fix
A dry run generates a list of findings. A finding is a specific, observable gap between expected and actual behaviour. Each finding must be triaged: is it a showstopper, a degradation, or a cosmetic issue? A showstopper means the event cannot proceed until the issue is resolved. A degradation means the event can proceed but with reduced quality or increased risk. A cosmetic issue means something looks or sounds wrong but does not affect the core content delivery.
Each finding needs an owner, a mitigation, and a verification step. The owner is the person responsible for resolving the issue. The mitigation is the specific action taken. The verification is the test that proves the mitigation worked. Without this structure, findings get lost in a Slack channel and resurface during the live show. I have learned to keep the findings log in a shared spreadsheet, not a chat tool, because chat is ephemeral and spreadsheets create accountability.
Common Failures and How to Provoke Them
After running dry runs for dozens of events, certain failures appear with depressing regularity. Here are the most common ones and how to test for them proactively.
Audio-Video Sync Drift
Lip-sync errors are the most noticeable and most common technical failure in live streams. They occur because audio and video take different paths through the production chain, each with its own latency. A dry run must include a clapperboard test: a visual cue (like a hand clap) that is recorded by the camera and the audio system simultaneously. Play back the recording and measure the offset in frames. Do this at the start of the dry run and again after two hours of continuous operation, because sync can drift over time as buffers fill and clocks diverge. If the drift exceeds two frames, you need to add delay compensation.
Slide Content Rendering Failures
Presenters build slides on their own machines, using fonts, colour spaces, and video codecs that are not available on the presentation computer. The result is missing fonts, black video boxes, and animations that stutter. During the dry run, open every slide deck on the actual presentation machine that will be used during the event. Check every slide for rendering errors. Play every embedded video from start to finish. If the presentation machine is a different operating system than the presenter’s machine, assume there will be problems and budget time to fix them.
Platform Configuration Mismatches
Streaming platforms have dozens of settings that must match the encoder configuration: resolution, frame rate, bitrate, keyframe interval, audio codec, audio bitrate, and channel count. A mismatch in any of these can cause the platform to reject the stream or transcode it with unacceptable quality loss. During the dry run, verify that the stream appears on the platform with the expected resolution and bitrate. Check the platform’s stream health dashboard for errors. If the platform offers a “stream test” mode that does not go live to attendees, use it.
When to Run the Dry Run
Timing is everything. A dry run that happens too early will be invalid because the setup has changed. A dry run that happens too late leaves no time to fix the problems it finds. The ideal window is 24 to 48 hours before the first live session. This provides enough time to re-cable, re-configure, or replace equipment without requiring a panic-driven overnight shift. For complex events, schedule two dry runs: a preliminary one 72 hours out to catch major integration issues, and a final one 24 hours out to verify fixes and catch last-minute changes.
Do not schedule the dry run for the evening before the event if the team has been working a 12-hour setup day. Fatigue causes mistakes, and a dry run conducted by an exhausted team will miss problems that a fresh team would catch. If the schedule forces an evening dry run, build in a two-hour break before it starts, and provide food and coffee. This is not a luxury. It is a risk-management measure.
Building a Culture That Values Dry Runs
The biggest obstacle to effective dry runs is not technical. It is cultural. When a dry run finds problems, someone has to own them. That person might feel defensive. The client might get nervous. The project manager might worry about the timeline. These pressures create an incentive to run a shallow dry run that finds nothing, so everyone can feel good and go to dinner. The antidote is to frame the dry run as a success precisely when it finds problems. A dry run that finds zero issues is a red flag, not a green light. It means the test was not rigorous enough.
One practice that helps is to celebrate findings. When someone catches a misconfigured audio bus or a mismatched frame rate, thank them publicly. Make it clear that finding problems during the dry run is professional, not embarrassing. Over time, this builds a team norm where people actively hunt for failures instead of passively hoping they do not exist.
FAQ
How long should a technical dry run take?
For a single-track hybrid event with moderate complexity, plan for three to four hours. This allows time for a full signal-chain walkthrough, induced failure tests, and a debrief. For multi-track events, budget four to six hours and consider running parallel dry runs for independent tracks, followed by a plenary integration test. Rushing a dry run into 90 minutes guarantees that only the happy path gets tested.
What if the client does not want to pay for a proper dry run?
Frame the dry run as insurance, not an optional extra. The cost of a four-hour dry run is a fraction of the cost of 30 minutes of dead air during a keynote, both in financial terms and in reputational damage. If the client still resists, document the risks in writing. Specify which failure modes will not be tested and what the potential impact could be. This protects your team and sometimes motivates the client to find the budget.
Should remote presenters participate in the dry run?
Yes, whenever possible. Remote presenters are the single largest source of variability in virtual and hybrid events. Their home network, their browser version, their webcam, and their technical skill all affect the stream quality. A dry run that does not include remote presenters is testing a fictional version of the event. If a presenter cannot attend the dry run, schedule a separate tech check with them and record the session so you have a reference for their setup.
What is the difference between a dry run and a rehearsal?
A dry run tests the technical infrastructure. A rehearsal tests the content and the talent. In a dry run, you do not need the CEO to practice their speech. You need the CEO’s laptop, connected to the venue network, sharing the actual slide deck, so you can verify that the embedded video plays and the slide advance works. Rehearsals and dry runs serve different purposes and should be scheduled separately. Combining them usually results in a bad rehearsal and a useless dry run.
The Dry Run as a Competitive Advantage
In an industry where most events still treat the dry run as a box to check, a rigorous dry run is a differentiator. It is the reason one production team delivers flawless streams while another spends the first 10 minutes of every session troubleshooting audio. It is the reason one team’s backup encoder actually works when the primary fails, while another team discovers during the keynote that their backup was never configured. The dry run is not the most glamorous part of event production, but it is the part that makes all the other parts look good. Run it like you mean it.