If a live stream fails, your audience sees one of four things: a spinning buffer, a frozen frame, a picture with no sound, or a page saying the broadcast has ended. What happens after that is decided almost entirely before the room is rigged. There is no move you can make at 2.14pm that a properly built stream has not already made for you.
That is the honest answer, and it is not a comforting one if your event is on Thursday. So here is the useful version. A live stream is a chain of six links: camera, switcher, encoder, connection, platform, viewer. Each one fails in its own way, and for each there is a specific thing that has to already be true for the show to survive it. Walk the chain with whoever is running your stream. Anywhere they can't tell you what happens is your exposure.
1. The camera
How it fails. Quietly, and usually one at a time. A battery that nobody swapped at the break. An SDI cable a banquet server steps on during the plated main. Autofocus hunting across the chief executive's opening line because someone left the lens on auto.
What has to already be true. More than one camera, and a director who can cut away from a dead one inside a second. A single locked-off camera is not a light-touch setup — it is the entire event resting on one cable. Mains power with batteries as the fallback, not the other way round, and the lenses locked off at rehearsal.
2. The switcher
How it fails. Visibly, and immediately, because everything passes through it. Software mixers running on a laptop are the common culprit — an operating system update queued behind the show, or thermal throttling in a warm ballroom. Then the human version: cutting to a camera mid-reposition, or putting the wrong slide on programme during the results section.
What has to already be true. The show machine is a show machine. No email client, no updates, no second job. The switcher sits on conditioned power rather than the same extension lead as the coffee urn. And there is a route around it — a single camera feed that can reach the encoder directly if the mixer stops, so the worst case is a plain wide shot rather than nothing at all. That is a patch decision made during setup and written on the signal plan, not a hardware purchase.
3. The encoder
How it fails. The encoder turns the programme feed into a stream, and it is the classic single point of failure. It overheats. It is set to a bitrate the connection cannot actually sustain, so it drops frames and the picture turns to porridge whenever anyone moves. It loses its connection to the platform and spends ninety seconds politely trying to reconnect while your audience watches a frozen frame.
What has to already be true. Two encoders, taking the same programme feed, sitting on two separate connections, both pushing live at the same time. Not one running with a second in a flight case. This is what redundant encoding means, and it is the highest-value item on this list: it converts the most common failure in live streaming from an incident into a shrug.
4. The connection
How it fails. More often than everything else combined. Guest Wi-Fi shared with 400 delegates who have all just found their seats and their phones. A conference network whose firewall blocks outbound RTMP, discovered at 8.40am. Upload is the number that matters, and it is the number nobody quotes you.
What has to already be true. A dedicated wired upload, ordered from the venue two to three weeks ahead — "we'll sort it on load-in" is how this goes wrong. Budget roughly 10 to 15 Mbps per simultaneous stream, and test it as a sustained push at show bitrate rather than a speed test — a line that peaks beautifully for eight seconds tells you nothing about hour two. Then a bonded cellular path as the second route, on separate infrastructure. If both run through the same venue switch, you have two cables and one point of failure.
5. The platform
How it fails. The platform has an outage. A regional CDN node degrades and one country buffers while everyone else is fine. Automated copyright matching mutes your audio because of the walk-in music. A privacy setting was never changed, so registrants arrive to "video unavailable" while the stream itself is perfectly healthy.
What has to already be true. Simulcast to a second destination, held live and unlisted, plus a decided way of telling the audience to move — a holding slide and a pre-drafted email sitting in someone's outbox. Music cleared before the day. And the privacy setting tested by an actual person outside your organisation, on a device outside your corporate network, because it always looks fine from inside.
This is the link we can engineer around least, and it is worth saying so plainly. You can hold a second destination and move an audience across in a couple of minutes. You cannot fix somebody else's content delivery network, and a vendor who implies otherwise is describing a wish.
6. The viewer
How it fails. The stream is entirely fine and one office still cannot watch. A corporate VPN blocking the player. A meeting-room TV running an app two versions behind. This is the failure that reaches you as "the stream is down", from the one person most likely to say it in front of your director.
What has to already be true. Someone watching as a viewer, from outside, on the platform the audience is actually using, for the whole show — not the engineer watching the encoder's own monitor. A named contact in each remote office who can describe what they see. And a stream engineer who can tell our stream failing from your network refusing it, which is a diagnosis rather than an opinion and takes about thirty seconds.
The file that survives regardless
Every link above concerns the live feed. The recording is a separate question, and should be built separately.
Cameras record to their own cards, the vision mixer records the programme feed to a local drive, and the encoder writes a local file as it streams. None of that touches the internet connection, so the day is captured even if the stream never reaches anybody. That does not make a failed broadcast acceptable. It does turn it from a lost event into a scheduling problem — the townhall goes out as a recording that afternoon, and the results briefing has a complete record for the corporate file.
The sentence to say to your leadership
You will be asked this in a steering meeting, probably by someone who wants forty seconds of reassurance rather than a signal diagram. Here it is in the plainest form we can write it:
"We're not relying on the venue's internet. Two encoders run at the same time on two separate connections, so if one drops, the feed carries on over the other without anyone having to notice or press anything. The session also records in the room, on a machine that never touches the stream, so we have the full file either way."
That answer holds up because every clause in it is checkable. If the company running your stream can't give you a version of it, ask which clause they can't say.
When a Zoom call with a co-host is genuinely enough
Sometimes none of this is worth buying.
If the audience is internal, nobody outside the company is watching and the content carries no regulatory weight, a Zoom or Teams meeting is the right tool. Add a co-host who can take over if the host's connection drops, switch cloud recording on before you start, and put the presenter on a cable rather than office Wi-Fi. That is a real backup plan, and it costs nothing.
Production earns its place when the audience is external, an executive is personally exposed, the content is regulated, or the day cannot be repeated. A fortnightly department update is none of those. If a vendor tells you it needs redundant encoding, they are selling you something. Our own live streaming work starts where the stakes do.
Failover, not backup
The distinction underneath this entire article is one word.
A failover switches without anyone deciding. A backup is a second thing that has to be noticed, chosen and switched to by a person who is already busy, in the two minutes of the day when everybody is looking at them. Under pressure, that second thing is not protection. It is another opportunity to fail.
So the question to put to whoever is running your stream is not whether they have backup. It is this: when the primary path drops, what switches, and does anybody have to notice for it to happen?
Frequently asked questions
What happens if a live stream fails mid-event? It depends which of the six links failed, and what was in place before load-in. A connection failure can be engineered around so nobody watching sees it. A platform outage usually can't, which is why a second destination matters.
What's the difference between a stream backup and a stream failover? A failover switches without anyone deciding. A backup is a second thing someone has to notice and switch to under pressure. Ask what switches automatically, and who has to notice.
Is venue Wi-Fi good enough for a live stream? Almost never for an event that matters — it's shared with the whole building and degrades as the room fills. Use a dedicated wired upload, roughly 10 to 15 Mbps per simultaneous stream, with bonded cellular on separate infrastructure as the second path.
If the stream drops, do we still have a recording? You do, if the recording was never dependent on the stream. Camera cards, a local programme record on the mixer and a local file on the encoder all survive an internet failure.
Do we need a production company, or is Zoom enough? For an internal session with one presenter and no external audience, Zoom with a co-host and cloud recording is genuinely enough. Buy production when the audience is external, the executive is exposed, the content is regulated, or the day can't be repeated.
Interframe runs broadcast and streaming for Singapore corporate events — cameras, vision mixing, redundant encoding and delivery on one technical plan, with one crew accountable for the whole chain. Tell us the venue, the audience and where the feed needs to reach, and we'll come back within one business day with a plan and a quote.