Your laptop just died. The show starts in four minutes. What happens next is entirely determined by decisions you made weeks ago, not by what you do in the next thirty seconds.
The crowd does not care that your backup drive is in the wrong road case. The client does not care that your vendor swapped out a unit at the last minute and nobody updated the signal chain. The show starts on time, or it does not, and if it does not, that moment lives forever in the room and in the client's memory.
I have been inside productions for Disney, the NBA, Dick Clark Productions, the Emmys, and hundreds of stages in between. I have watched technology fail at every budget level, in every format, in front of every size audience. The productions that survived those failures, the ones where nobody in the house ever knew something went wrong, all had one thing in common. They had thought through the failure before it happened.
That is what a real redundancy protocol is. It is not a backup hard drive taped to a case. It is a documented, rehearsed, role-assigned plan for what happens when the thing you are counting on stops working. Here is how to actually build one.
Start With Your Single Points of Failure
Every show has them. A single point of failure is any node in your signal chain, your power path, your playback system, or your communication network where, if that one thing goes down, the show stops. Your first job is to map every one of them.
Walk your entire technical flow from source to audience. Audio playback, video sources, lighting control, show control triggers, power distribution, communication systems, internet connectivity if you are streaming. At each node, ask one question: if this dies right now, what happens? If the answer is the show stops, you have found a single point of failure and you need a plan for it.
Write it down. Not in your head. On paper or in a shared document your whole team can access. A redundancy protocol that lives only in the lead engineer's head is not a protocol. It is a prayer.
Build Redundancy Into Layers, Not Just Gear
Most people think redundancy means having a spare. Bring a backup laptop, carry a second mic. That is a start, but it is not a protocol. Real redundancy works in layers, covering gear, signal path, power, and people.
Gear Redundancy
Yes, you need a spare. But the spare needs to be configured identically to the primary, powered on, and hot-swappable whenever possible. A backup laptop that takes eight minutes to boot and reload a show file is not redundancy. It is a delay. Pre-load your backup. Keep it live. Test it before doors open.
Signal Path Redundancy
If your primary audio path runs Dante over a network switch, your backup should not also run through that same switch. One switch failure and both paths die. Route your backup through a different physical path. This matters more than having twice the gear.
Power Redundancy
This is the layer people skip most often and regret most loudly. Know where your circuits are. Know what is on each one. If critical systems share a circuit, fix that before load-in is complete. Uninterruptible power supplies on your show-critical gear are not optional on a serious production; they are standard.
People Redundancy
If only one crew member knows how to execute the switchover, you do not have a redundancy protocol. You have a dependency. Every critical technical role needs at least one other crew member who knows exactly what to do if the primary operator goes down, gets pulled away, or freezes under pressure. Train them before the show, not during it.
Assign the Roles Before You Need Them
When something fails mid-show, the worst thing that can happen is hesitation. People looking at each other. Someone waiting for permission. At the highest level of production, failure response is choreographed the same way the show itself is choreographed. There is a decision tree, and everyone knows their place in it.
Document who calls the switchover. Document who executes it. Document who communicates to the client or the talent. Those are three different roles and they cannot belong to the same person. If your lead engineer is executing a failover, they cannot simultaneously manage the client's anxiety at front of house. Someone else owns that conversation, and they need to know it before curtain.
For a closer look at how we structure crew roles and production systems, visit the services page to see what a fully built-out show framework looks like.
Test It Like It Is Real
A redundancy protocol you have never actually run is theoretical. The only way to know whether your failover holds under pressure is to simulate the failure in a low-stakes environment. Pull the cable. Kill the primary. Force the switch. Time it. Do it again. Do it until the response is muscle memory for every person on your crew.
This is what separates productions that hold together from the ones that unravel on camera. The teams that look calm during a failure are not calm because nothing bad ever happens to them. They are calm because they have practiced being in the fire.
Document It and Update It Every Time
Your redundancy protocol is a living document. It belongs in your show file, it needs to be accessible to your whole team, and it must be updated after every production. What failed, how you responded, what held, what you would change next time. That feedback loop is how your protocol actually sharpens over a career instead of stagnating at year one.
- Map every single point of failure before load-in
- Build redundancy at the gear, signal, power, and personnel level
- Pre-configure backups and keep them live, not sealed in a case
- Assign and rehearse failure response roles before the show
- Simulate failures during rehearsal and time your response
- Document outcomes and update your protocol after every production
The cost of skipping this is real and specific. I have watched a single cable failure turn into fifteen minutes of dead silence in front of a paying audience. I have seen clients never call a production company again after one bad night. Gear fails. Software glitches. Power drops. The question is never whether something will go wrong; the question is whether you built the system that absorbs it before the audience ever notices.
If you want help building a redundancy framework that fits your show type, your crew size, and your actual technical footprint, that is exactly the work we do at Ascend & Achieve. Reach out and let us show you what a production-ready protocol looks like for your operation.