Your main stream just went down. The encoder froze, the CDN hiccupped, or someone tripped over the Ethernet cable. 2,000 remote viewers are staring at a buffering spinner. The client is calling. You have no backup.
This is the nightmare scenario that every streaming professional has either lived through or fears. And the fix is straightforward: run a backup live stream.
This guide walks through why backup streams matter, how to architect redundancy, and how to set one up step by step.
Why Every Live Stream Needs a Backup
Live streaming is inherently fragile. The signal chain from camera to viewer has dozens of failure points:
- Encoder failure — hardware or software crash, thermal throttle, driver conflict
- Network interruption — ISP drop, switch failure, Wi-Fi congestion, cable disconnect
- CDN outage — rare but catastrophic when it happens
- Platform issues — YouTube/Vimeo/Facebook ingest servers occasionally reject connections
- Human error — wrong stream key, accidentally stopping the stream, misconfigured bitrate
Any one of these kills your stream. With no backup, your options are: fix it fast (while 2,000 people watch a loading spinner) or accept the loss.
With a backup stream, your options are: switch to the backup feed while you fix the primary. The audience may not even notice.
Backup Stream Architecture
There are several levels of streaming redundancy. Choose the level that matches your event's stakes:
Level 1: Redundant Encoder
Run two encoders ingesting the same video source. Both push to the same streaming platform. If Encoder A fails, Encoder B is already live.
Pros: Simple. Covers the most common failure (encoder crash). Cons: Doesn't protect against network or platform failures. Both encoders share the same upstream path.
Level 2: Redundant Path
Run two encoders pushing to two different RTMP endpoints — either two accounts on the same platform or two different platforms entirely. Your streaming embed points to the primary. If it fails, you swap the embed URL to the backup.
Pros: Protects against encoder AND platform failures. Cons: URL swap takes time unless you have an intermediate player.
Level 3: Redundant Path with Automatic Failover
Same as Level 2, but with a hosted player that monitors both streams and automatically switches to the backup if the primary drops. The audience sees a single URL that never changes.
Pros: Seamless failover. Maximum reliability. Cons: Requires a player that supports multi-source failover.
For most professional events, Level 2 or 3 is the right choice. Level 1 is better than nothing but leaves too many single points of failure.
Step-by-Step: Setting Up a Backup Live Stream
Here's the practical walkthrough for a Level 2 setup — two independent RTMP paths with manual switchover capability.
Step 1: Prepare Your Primary Stream
This is your existing stream — YouTube Live, Vimeo, Facebook Live, or another RTMP-compatible platform. Make sure it's configured and tested:
- Stream key is set and tested
- Encoder is configured with your target bitrate (typically 4,500-6,000 kbps for 1080p)
- You've verified the connection works with a test stream
Step 2: Set Up the Backup RTMP Ingest
You need a second RTMP endpoint that's independent of your primary platform. This is where a dedicated backup stream service comes in.
Create a new live input with:
- RTMP ingest URL — the server URL your encoder will push to
- Stream key — unique to this input
- Recording mode — set to automatic so you capture the backup feed even if you don't use it live
Step 3: Configure Your Encoder for Dual Output
Most professional encoders support multiple output destinations. In OBS Studio:
- Go to Settings → Stream
- Set your primary destination (e.g., YouTube)
- Install the Multiple RTMP Outputs plugin, or use the Custom service for a second output
- Add your backup RTMP URL and stream key
In hardware encoders like the Blackmagic ATEM or Teradek VidiU:
- Configure the primary output to your main platform
- Configure the secondary output to your backup RTMP endpoint
Both outputs should use the same source video feed. The encoder compresses and pushes to both destinations simultaneously.
Step 4: Verify Both Streams
Before the event:
- Start both streams
- Confirm the primary is live on your main platform
- Confirm the backup is ingesting and recording
- Open the backup's hosted player URL to verify playback
- Let both run for at least 5 minutes to catch intermittent issues
Step 5: Prepare the Switchover Plan
During the event, if the primary fails:
Manual switchover:
- Send the backup player URL to your audience (via email update, chat message, or social media post)
- Embed the backup player URL in your event page, replacing the primary embed
Hosted player failover: If you're using a hosted player that supports multiple sources, configure it to monitor the primary stream health and automatically switch to the backup URL if the primary drops.
Step 6: Monitor During the Event
Assign someone to monitor both streams throughout the event. They should have:
- The primary platform dashboard open
- The backup stream dashboard open
- The hosted player open in a browser
- A communication channel to the event producer
If the primary drops, they execute the switchover. If the backup drops, they alert the team to fix it while the primary is still running.
Bandwidth Considerations
Running two simultaneous RTMP outputs doubles your upstream bandwidth requirement. For 1080p at 6,000 kbps:
- Single stream: ~7 Mbps upstream (video + audio + overhead)
- Dual stream: ~14 Mbps upstream
Make sure your venue's internet connection can handle this. For critical events, consider a bonded cellular connection or dedicated fiber as a secondary network path — otherwise both streams fail if the venue internet drops.
Bitrate Strategy
For the backup stream, you can reduce bitrate to conserve bandwidth:
| Stream | Resolution | Bitrate | Purpose |
|---|---|---|---|
| Primary | 1080p | 6,000 kbps | Best quality for audience |
| Backup | 720p | 3,000 kbps | Acceptable quality, lower bandwidth |
A 720p backup is far better than no backup. The audience will accept slightly lower quality over a dead stream.
Recording as a Safety Net
Even if you never need to switch to the backup during the live event, the backup stream's recording is invaluable:
- Insurance against primary recording failure — some platforms occasionally fail to save recordings
- Clean capture — no platform overlays, no chat replay baked in
- Immediate availability — you don't need to wait for the platform to process the recording
Set recording mode to automatic so every backup stream session captures footage whether you use it live or not.
Common Mistakes
Same network, same failure. If both your primary and backup encoders are on the same network switch, a switch failure kills both. Use separate network paths where possible.
Untested backup. Setting up a backup RTMP endpoint and never testing it is almost worse than not having one — it gives false confidence. Test every backup before every event.
No monitoring. A backup stream that's been down for 30 minutes without anyone noticing is useless when you need it. Active monitoring is non-negotiable.
Forgetting audio. Video redundancy is obvious. Audio redundancy is often overlooked. Make sure both encoders are receiving the same audio feed, and test both streams with sound.
Setting Up a Backup Stream with LGL
Let's Go Live's Backup Live Stream tool is built for exactly this use case. Here's the quick setup:
- Create a new live input in your workspace — you'll get an RTMP URL and stream key
- Configure your encoder to push to the LGL RTMP endpoint as a secondary output
- Share the hosted player URL as your failover destination
- Monitor the stream status from your workspace dashboard
The hosted player page is ready to share with your audience if you need to switch. Recording is automatic — every session is captured.
For production teams managing multiple events, the workspace model lets you create separate live inputs per client, track usage per stream, and manage billing in one place.
Conclusion
A backup live stream is production insurance. The cost of setting one up — a few minutes of configuration and modest additional bandwidth — is trivially small compared to the cost of a failed stream: angry clients, lost viewers, and a reputation hit.
If you're streaming a live event, you should have a backup. No exceptions.
Set up a backup stream in your workspace — contact our team to get started with LGL's streaming tools.