Why a 24/7 YouTube stream may not become a VOD

Step 1: Read the rule as a clock

YouTube’s page on archiving live streams says a stream under 12 hours can be archived for you automatically. It also says a stream that goes past 12 hours “may not be captured at all.” It recommends keeping a local recording as a backup. I re-read it on Oct 2, 2026. That is the whole official rule. It names a limit and promises nothing beyond it.

A 24/7 stream is one very long broadcast unless something ends it. So the archive question is settled at hour twelve, long before anyone looks. In our run the miss sent no notice that we saw. That part is from our own run, not re-checked against current docs.

What does the channel show today? A broadcast leaves a public entry even when its recording is lost, so I checked each entry’s watch page in the window, Aug 15 – Oct 2, 2026 (49 days). Of the 22 public stream entries in the window, 6 still play back and 16 do not (checked Oct 3, 2026). The check reads the playability status on each public watch page. It does not play the video through.

Step 2: Count your broadcasts

In our setup, one encoder sent two feeds: a horizontal one and a vertical one for phones. Each feed ran as its own broadcast, with its own stream key and its own 12-hour clock. That is from our own run. A check that looks at one broadcast misses half the entries.

This was not YouTube’s built-in Dual stream setting. The help page describes that as one go-live notification and a shared stream URL, and says it is on by default for streams made from the Live Control Room, so look at yours. Under it, a horizontal feed and an Encoder-mode vertical feed can be one broadcast, not two. We have not tested how archiving behaves under the built-in setting.

Every entry that plays ran under 12 hours. The longest of them is listed at 38,272 seconds, about 10.6 hours. All 16 entries over 12 hours, from 22.6 hours up, show that same message. That is one channel and one window, not a law. But it is exactly what “may not be captured” looks like. What I take from it: past twelve hours you leave the outcome to something you cannot control, and a listing that looks healthy proves nothing.

Step 3: Set auto-stop before you connect

Cutting your encoder is easy. Making YouTube end the broadcast when you do is the hard part. The API reference describes auto-stop as ending a broadcast around one minute after the channel owner stops sending video, and auto-start as beginning one when video arrives on the bound stream. YouTube’s stream-settings help page lists both as “Auto-start & auto-stop” and says that with them on, you can start or stop streaming from your encoder.

Our notes add what the docs leave out. In our setup, with auto-stop off, stopping the encoder did not end the broadcast. YouTube resumed the same one afterward. We did not test every gap length, and some of our broadcasts did end for reasons we did not pin down. Treat this as one setup’s behavior, from our own notes and not re-checked against current docs.

Step 4: Cut on a fixed clock

Pick a segment length well under the wall and cut on the wall clock. Our plan is eight-hour segments with three cuts a day, at 06:00, 14:00 and 22:00 Pacific time.

06:00  cut, ~3 min gap
  |    8 hours
14:00  cut, ~3 min gap
  |    8 hours
22:00  cut, ~3 min gap
  |    8 hours
06:00  cut, ~3 min gap

Each cut stops the encoder, waits about three minutes, then starts it again, on both feeds. Three minutes is roughly three times the one minute the API reference describes. That margin is my choice, not a documented number. A hard ceiling of 11 hours means the scheduler refuses to plan past it.

What we accepted in exchange: three go-live notifications a day, about three minutes of dead air per cut, and two videos per cut, one per feed. That is six near-duplicate videos a day. These are design choices made on Sep 7, 2026, not measured results. The schedule has not run live.

Step 5: Three rules for whatever does the cutting

1. Enforce the minimum gap in code, in one place. A stop request can fail after the encoder has already stopped: a timeout, a dropped connection. In our first draft, a failed stop sent the code straight to the restart with no gap, which would have left YouTube on the same broadcast. We caught it before any live run. Put the floor inside the restart routine, not at each caller.
2. “Streaming” is a claim, not proof. Our encoder, with auto-reconnect on, reported a failing connection as active for minutes while it retried, because its “active” flag counts reconnecting. Count a feed as live only when the bytes sent rise between two samples a few seconds apart and the output is not reconnecting.
3. A reboot must never put you live unannounced. If the machine started after the last recorded step, treat the plan as stale and wait for a person.

After every cut, compare each feed’s new start time with its previous stop time. If a feed did not start a new broadcast twice in a row, pause everything and suspect auto-stop first.

Run it yourself

• List every broadcast your feeds create. Each broadcast has its own 12-hour clock. Two feeds can be two broadcasts, as ours were, or one, under YouTube’s built-in Dual stream.
• With the encoder disconnected, open the Live Control Room and turn on auto-start and auto-stop for each broadcast.
• Choose a segment length well under 12 hours and a fixed wall-clock schedule.
• Set a gap several times the one minute the API reference describes, and enforce it in one place.
• Run one real cut. Confirm each broadcast was replaced by a new one. Then open each finished segment and play it near the end. A lost recording can still list as a public video with its full duration. The help page does not say how long a recording takes to appear.
• Record locally too. YouTube recommends it.
• Hold after any reboot until a person says go.

Sources

• Archive live streams (YouTube Help). Re-checked Oct 2, 2026. Supports the 12-hour line, “may not be captured,” and the local-backup recommendation.
• LiveBroadcasts resource (YouTube Data API). Re-checked Oct 2, 2026. Supports the auto-start and auto-stop descriptions, including “around one minute.”
• LiveBroadcasts: transition (YouTube Data API). Re-checked Oct 2, 2026. Supports complete ending a broadcast.
• LiveBroadcasts: update (YouTube Data API). Re-checked Oct 2, 2026. Supports the persistent-broadcast restriction on auto-stop.
• Quota calculator (YouTube Data API). Re-checked Oct 2, 2026. Supports 50 units for a transition.
• Manage live stream settings (YouTube Help). Re-checked Oct 2, 2026. Supports the “Auto-start & auto-stop” setting.
• Get started with live streaming (YouTube Help). Re-checked Oct 2, 2026. Supports the Dual stream description.
• Our own check: each public stream entry’s watch page, read Oct 3, 2026, for the playability status. Entry list: YouTube Data API via our own tooling.
• Our own run: the two-broadcast setup, the greyed-out toggles and the gap behavior. Not re-checked against current docs.