One of the hardest things to explain about live production is that you can do a hundred shows successfully and still run into something completely unexpected on show 101. It’s just the reality of building temporary systems in constantly changing environments with dozens of moving parts, multiple vendors, evolving technology, and very little room for error.
Most shows go incredibly well. Thousands of productions happen every year with very few issues beyond the occasional small hiccup that gets solved before anyone in the audience even notices. But no matter how experienced the team is or how carefully a system is designed, there is always an underlying truth in live production: At some point, you are still relying on technology, infrastructure, and the venue to behave the way they’re supposed to. And sometimes they don’t.
That’s where the conversation around redundancy starts.
People often think redundancy simply means “having a backup,” but real redundancy is much more intentional than that. It starts with asking a very specific question: what exactly are we trying to protect against? Is the concern a console failure? A network interruption? Wireless interference? Power instability? A stream dropout?
Each potential failure point requires a different solution, and each additional layer of protection adds complexity, cost, setup time, and operational considerations. That’s why redundancy is less about checking a box and more about understanding risk.
A good example of this happened during a live show where Dante audio on the network would randomly disappear for three to five seconds at a time without throwing any obvious errors. No alarms or visible failures. Just intermittent silence. The show still happened, and fortunately the team was able to piece together a clean record afterward to create a complete transcript of the call. But situations like that are a reminder that failures are rarely simple or isolated.
In that case, there were multiple vendors involved and network infrastructure that wasn’t fully isolated, which potentially created unexpected interaction between systems, as well as the console. Searching for a specific cause can become its own conquest, and sometimes there isn’t a clear answer, just best practices moving forward. Nobody walked into the day anticipating that exact problem. Sometimes issues only reveal themselves once every piece of the ecosystem is live and talking to each other in real time. That’s also why true redundancy can become a rabbit hole very quickly.
You can build backup paths for almost anything if the client wants the protection badly enough. One recent solution involved wireless microphones traveling through network infrastructure to the console, while completely separate hardwired microphones bypassed the network entirely as a parallel analog path. Digital redundancy from source to destination, analog redundancy underneath it. Independent paths designed specifically around the risks identified for that show.
But every additional layer requires more time, more labor, more infrastructure, and more testing to ensure the backup itself actually works when it’s needed.
At a certain point, redundancy becomes less of a technical question and more of a philosophical one: How risk averse is the client willing to be?
Because there is no such thing as eliminating every possible point of failure. You can absolutely reduce risk and you can plan intelligently. You can build thoughtful systems and prepare for catastrophic scenarios. But live events are not perfect, and they are definitely not an exact science. Some things will go right, some things will go wrong. That’s how it goes.
That reality tends to humble people who have spent enough time in production. Whenever we see a technical issue happening on a major broadcast or event, the reaction usually isn’t, “That would never happen to us.” It’s almost always curiosity first. What actually caused that? Because these failures are rarely the result of one obvious mistake. More often, it’s a chain of small contributing factors that compound in real time.
The same thing happens after shows when people reduce an audio experience down to “the sound was terrible.” Maybe it was. But there are usually layers underneath that statement that most people never see. Was the room acoustically difficult? Did a processor malfunction? Was someone seated under a damaged speaker? Did the production schedule allow enough time to properly tune the system for every seat in the room?
The reality is that live production is a constant balance between preparation, limitation, adaptation, and time. And that’s why experienced teams matter.
Not because they can promise perfection, but because they know how to think through risk, build systems that protect the show as much as possible, and respond calmly when something unexpected inevitably happens anyway.
At the end of the day, redundancy isn’t about fear. It’s about responsibility. It’s about understanding where failure could happen, deciding what level of protection makes sense for the production, and building systems that support the show accordingly.
Because in high-stakes environments, the goal isn’t to pretend technical failures are impossible. The goal is to be prepared when they aren’t.