What a Technical Dry Run Actually Is (and Why Most Teams Get It Wrong)
A technical dry run is a structured, time-boxed rehearsal of the critical infrastructure pathways that deliver content during a live, hybrid, or virtual knowledge event. It is not a full-dress rehearsal, not a content review, and certainly not a meeting where someone reads slides aloud while everyone else checks email. In conference technology operations, the dry run isolates the physical and digital handoffs—audio routing, video switching, stream ingestion, caption relay, platform failover—and tests them under conditions that approximate show day. Adjacent concepts include the table read (content-focused), the integration test (vendor-specific), and the load test (scale-focused). For failure engineers and event producers, the dry run is the last defensible checkpoint before the audience arrives. When it is done well, it surfaces latent failures. When it is done poorly, it wastes the one resource nobody can recover: the focused attention of the people who will be on the bridge when things break.
Most dry runs fail because they lack a clear scope, a defined success criterion, and a facilitator who is willing to call a stop when the test becomes a meeting. The result is a ritual that burns two hours, confirms nothing, and leaves the team with a false sense of readiness. This article outlines a method for running a dry run that respects the time of competent professionals, produces actionable data, and actually reduces the probability of a live failure. It draws on patterns from network operations, live broadcast engineering, and the particular chaos of hybrid event venues where physical room signals must marry digital platforms without a common clock.
Why Most Dry Runs Are a Waste of Time
The typical dry run for a knowledge conference follows a predictable script. Someone shares a screen, clicks through slides, and asks if everyone can hear. A remote speaker joins, says “hello, can you hear me?” and then drops off. The in-room team confirms the projector works. Someone asks if the recording is on. The producer says “we’ll test that later.” After 90 minutes, the meeting ends with a vague sense that things are fine. They are not fine. What just happened was a content walkthrough with a light audio check, not a technical dry run. The team has tested nothing that will actually fail under load.
This pattern persists because dry runs are often scheduled by project managers who conflate technical readiness with content readiness. The agenda becomes a catch-all, and the most expensive people in the room—the engineers who built the signal chain—spend their time waiting for a presenter to find the right slide. The dry run becomes a social ritual instead of an engineering exercise. The fix is to separate the technical dry run from the content rehearsal entirely, give it a different name if necessary, and staff it only with the people who own the infrastructure.
Designing a Dry Run That Produces Evidence, Not Opinions
A useful technical dry run starts with a test plan that reads like a network validation script, not a run-of-show. Each test case must have a defined input, an expected output, and a pass/fail criterion. The goal is to generate evidence that the signal chain works end-to-end, and to discover where it breaks. This means testing the unhappy paths: what happens when the primary encoder loses sync, when the backup stream key is invalid, when the caption relay drops mid-sentence, when the in-room confidence monitor loses power. If you are not testing failure modes, you are not doing a dry run; you are doing a hope-for-the-best walkthrough.
For hybrid events, the room-to-platform handoff is the most fragile link. A common failure occurs when the physical audio mix—perfectly balanced for the room—hits the digital platform with no compression, no loudness normalization, and a 12 dB discrepancy between the podium mic and the wireless handheld. The dry run must include a measurement pass: play a known reference tone through the entire chain, measure the level at the platform ingest point, and compare it to the platform’s target loudness specification. This is not a subjective “sounds good” check. It is a quantitative validation that prevents the remote audience from riding their volume control all day.
Pre-Dry Run: The Checklist That Prevents Chaos
Before anyone dials into a dry run, the technical lead should complete a solo validation pass. This is not the dry run itself; it is the prerequisite work that ensures the dry run will be productive. The checklist includes:
- Signal path continuity: Verify that every device in the chain powers on, passes signal, and reports no errors. This includes capture cards, embedders/de-embedders, Dante or NDI endpoints, and hardware encoders.
- Platform configuration: Confirm that the streaming destination (Zoom Events, ON24, vMix Call, etc.) has the correct stream key, bitrate, and resolution settings. A mistyped stream key discovered during the dry run wastes 20 minutes while everyone watches the engineer retype it.
- Network baseline: Run a 60-second iPerf test to the ingest server and record jitter, packet loss, and throughput. If the venue network is already saturated by a concurrent event, you need to know before the dry run, not during it.
- Backup path validation: Confirm that the backup encoder, backup stream key, and backup network path (cellular, secondary ISP) are functional and can be activated within the target switchover time.
This pre-flight check takes 30–45 minutes and eliminates the most common time-wasters from the group dry run. It also produces a baseline dataset that the team can reference if something degrades between the dry run and show day.
Structuring the Dry Run: A 60-Minute Protocol
The dry run itself should be constrained to 60 minutes. Longer sessions produce fatigue, encourage scope creep, and reduce the likelihood that participants will remain engaged for the full duration. The protocol below assumes a hybrid event with a physical stage, remote presenters, and a streaming platform. Adapt the blocks to your specific topology, but keep the structure: inject, measure, break, recover.
Block 1: Signal Injection and Measurement (15 minutes)
Start by injecting a known reference signal into every input path. For audio, use a 1 kHz tone at -20 dBFS from a signal generator app or a pre-recorded file. For video, use color bars or a test pattern with embedded audio tone. Measure the level at every monitoring point: the audio console’s main output, the encoder’s input meters, the platform’s stream health dashboard. Document the measured levels and compare them to the expected values. If the platform expects -16 LUFS integrated and you are hitting -23 LUFS, you have a gain staging problem that will make remote presenters sound quiet and distant. Fix it now, not during the CEO’s keynote.
For video, confirm that the resolution and frame rate at the encoder input match the platform’s expected ingest settings. A 1080p59.94 signal sent to a platform expecting 1080p30 will trigger a re-encode on the platform side, adding latency and potentially introducing artifacts. This is a common failure in events that mix broadcast cameras (59.94 Hz) with computer sources (60 Hz). The dry run is the time to decide which standard will govern and to insert a frame rate converter if needed.
Block 2: Handoff and Interoperability Testing (20 minutes)
This block tests the boundaries where one system hands off to another. For hybrid events, the most dangerous handoff is the room-to-platform transition, but there are others: the slide advance relay, the caption encoder, the interpreter console, the remote presenter return feed. Each handoff should be tested with a specific stimulus and a measurable response. For example, to test the slide advance relay, send 10 forward commands from the presentation remote and confirm that the platform receives exactly 10 slide changes with no duplicates and no missed commands. This is not a “looks good” test; it is a packet count.
Remote presenter handoffs deserve special attention. The pattern described in Why Hybrid Events Fall Apart at the Room-to-Chat Handoff applies here: the moment a remote speaker finishes their presentation and the producer switches back to the room, the platform often drops the remote speaker’s audio return, leaving them unable to hear the Q&A. The dry run must simulate this exact transition and verify that the remote speaker’s return feed remains active. If the platform does not support this natively, the team needs a workaround—a separate audio bridge, a phone line, a backchannel chat—and that workaround must be tested during the dry run.
Block 3: Failure Injection (15 minutes)
This is the block that separates a real dry run from a walkthrough. The team deliberately introduces failures and observes the system’s response. The failures should be drawn from a pre-defined list based on the event’s risk register, not improvised on the spot. Examples:
- Disconnect the primary encoder’s network cable. Measure the time to switch to the backup encoder and the duration of the stream interruption. If the target is under 5 seconds and the actual is 18 seconds, you have a problem with the platform’s failover logic or the backup encoder’s GOP structure.
- Mute the room’s main audio console. Confirm that the backup audio feed (a separate mix from the monitor console or a direct out from a key mic) is present at the platform ingest and is intelligible. Many backup audio feeds are never tested and turn out to be post-fader, meaning they go silent when the main mix is muted.
- Kill the venue’s primary internet connection. Verify that the cellular backup link takes over and that the stream continues without a full reconnection handshake. Some platforms require a new stream key when the source IP changes; if that is the case, the team needs a documented procedure for updating the stream key under pressure.
Each injected failure should be logged with the time, the observed effect, and the recovery action. This log becomes the basis for the post-dry-run report and the show-day runbook. If a failure cannot be resolved within the dry run, it becomes a blocking issue that must be addressed before the event proceeds.
Block 4: Communication Loop Validation (10 minutes)
Technical failures are manageable if the team can communicate. The dry run must validate that all communication channels—intercom, backchannel chat, phone bridge, hand signals—are working and that every team member knows how to use them. This is not the time to discover that the A2’s intercom beltpack has a dead battery or that the remote captioner cannot hear the program audio because they are on the wrong mix-minus. Run a quick comms check: the technical director calls each position, confirms two-way audio, and verifies that the backup channel (usually a text chat or phone number) is accessible.
For remote team members, latency in the communication channel can create dangerous coordination gaps. If the stream operator is on a cellular connection with 800 ms of latency, a “switch to backup now” command will arrive almost a full second after it is spoken. The dry run should measure the round-trip latency of the primary and backup comms channels and document the expected delay. On show day, the producer can then account for that delay when calling cues.
Post-Dry Run: The 15-Minute Debrief That Replaces a 60-Minute Meeting
The dry run ends with a focused debrief, not a free-form discussion. The technical lead reviews each test case, states whether it passed or failed, and assigns an owner to any unresolved issue. The output is a one-page report with three sections: what worked, what broke, and what changed. The “what changed” section is the most important because it captures the configuration tweaks, signal path adjustments, and procedural updates made during the dry run. If the team changed the encoder’s audio bitrate from 128 kbps to 256 kbps to fix a compression artifact, that change must be documented. Otherwise, someone will “optimize” the settings back to the original value the night before the event.
This report should be distributed within 30 minutes of the dry run ending. It serves as the authoritative reference for the show-day setup and protects the team from last-minute tinkering. It also creates an institutional memory: over multiple events, the accumulated dry-run reports become a dataset that reveals recurring failure patterns, unreliable vendors, and infrastructure that needs replacement.
Common Dry Run Anti-Patterns
Even teams that understand the theory fall into predictable traps. Recognizing these anti-patterns is half the battle.
The “We’ll Fix It on the Day” Fallacy. This is the most expensive sentence in event technology. It assumes that the problem is trivial, that the fix is known, and that there will be time to implement it during the chaos of show setup. None of these assumptions hold. The dry run is the time to fix problems, precisely because the pressure is low and the engineers are fresh.
The All-Hands Dry Run. Inviting stakeholders who have no operational role—marketing managers, content owners, executive producers—turns the dry run into a performance. Engineers self-censor, problems are minimized, and the session becomes a demonstration of readiness rather than a search for failure. Keep the attendee list to the people who will touch the equipment on show day.
The Infinite Dry Run. Without a hard stop, dry runs expand to fill the available time. The facilitator must enforce the schedule ruthlessly. If a test case cannot be completed in its allocated block, it is logged as a failure and deferred to a follow-up session. Do not steal time from the failure injection block to finish a measurement that could have been done in the pre-check.
FAQ
How is a technical dry run different from a full rehearsal?
A technical dry run tests the infrastructure pathways—audio, video, network, control—without content or presenters. A full rehearsal includes presenters, slides, and timing, and is focused on content flow and speaker performance. The two should be scheduled separately. Combining them guarantees that neither is done well.
What is the minimum equipment needed for a useful dry run?
You need the actual signal chain that will be used on show day, or a representative subset of it. A dry run on a laptop with a webcam when the event uses a broadcast camera and a hardware encoder is not useful. At minimum, you need the primary and backup encoders, the audio console, the streaming platform, and the network paths. If you cannot access the venue, bring the portable equipment to a test bench and simulate the venue’s network conditions.
How often should we run a dry run for a recurring event series?
For a weekly webinar using the same equipment and platform, a full dry run before each event is excessive. Instead, run a 10-minute signal check before each session and a full dry run whenever something changes: a new platform version, a different venue, a new encoder, or a new team member. For large annual conferences, schedule at least two dry runs: one focused on individual subsystems a week before the event, and one end-to-end dry run 48 hours before doors open.
What if the dry run reveals a problem we cannot fix in time?
This is a valuable outcome, not a failure. The dry run’s purpose is to surface problems. If a problem cannot be fixed, the team has three options: implement a workaround, adjust the event design to avoid the failure mode, or accept the risk and prepare a contingency plan. The worst response is to ignore the problem and hope it does not recur on show day. Document the issue, communicate it to the stakeholders who need to know, and update the runbook with the contingency procedure.