What Twitch writes about the cap.
The Broadcast Guidelines page states the ceiling in three sentences. It is a hard number, not a setting in the dashboard.
The third sentence is the one worth reading twice. Twitch declines to describe what happens next, and points at the encoder instead.
Reconnection is the streamer's problem, in Twitch's own wording. Nothing on that page promises a broadcast resumes on its own.
48 hours per broadcast, not per day.
The clock counts one continuous broadcast, from the moment the encoder connects to the moment it stops. Ending a stream resets it to zero.
Nothing accumulates across days. Streaming ten hours a day for a week never approaches the cap, because each day is its own broadcast.
Only a session that stays connected can reach 48 hours. The cap is a 24/7 problem, and almost nobody else's.
No warning, no dialog.
There is no countdown in Creator Dashboard, no banner at 48 hours minus one, and no confirmation before the ingest closes.
The encoder simply loses its connection. In OBS it looks like any other dropped connection.
Twitch publishes no notice on that page either. If you want a warning, you keep the clock yourself. The tool below does it.
What actually happens at the cap.
Four things are observable from outside, and only four.
The broadcast ends. The channel goes offline in the directory, and viewers on the page get the offline screen instead of video.
The past broadcast stops where the session stopped. A VOD that was mid-file when the cap hit is cut at that point, not at the end of the content.
Reconnecting starts a new broadcast, with a fresh clock and a fresh past broadcast.
- The stream ends at the cap, wherever the playback happens to be.
- Viewers see the offline screen, and the channel leaves the live directory.
- The past broadcast is cut at the moment of the disconnect.
- A reconnect is a new broadcast, with its own VOD and its own clock.
Does the stream come back on its own?
Twitch restarts nothing. Whether the channel comes back depends on the encoder, which is what the third sentence of the guidelines means.
OBS retries by itself when Automatically Reconnect is ticked, in Settings, then Advanced. The box is ticked by default.
A retry that succeeds opens a new broadcast. The channel is live again, with a new past broadcast and a clock back at zero.
Any other encoder needs the same check. One that does not retry leaves the channel offline until someone presses Start.
- Twitch never restarts a broadcast by itself.
- OBS: Settings, Advanced, Automatically Reconnect, ticked by default.
- A successful retry is a new broadcast, with a new past broadcast.
- No retry means offline until someone restarts by hand.
What you keep: followers, schedule, position.
The cap is a disconnect, not a penalty. Nothing about the channel is touched by it, and no Twitch page describes any consequence beyond the stream ending.
Your followers, subscribers, channel points and their balances, the schedule, the tags, the title, the category and the panels all survive unchanged.
Affiliate and Partner status are untouched, and the hours already streamed stay counted where Twitch counts them. Reaching the cap is not a violation of anything.
What you lose is continuity, and only continuity. The list below is the whole cost.
- Followers and subscribers: unchanged.
- Channel points, predictions and their balances: unchanged.
- Schedule, tags, title, category, panels: unchanged.
- Affiliate or Partner status, and the hours already counted: unchanged.
- Your position in the directory: restored as soon as the new broadcast starts.
What you lose: one VOD's continuity.
The past broadcast closes at the second of the disconnect. A film cut at minute forty is stored cut at minute forty, and the rest lives in the next VOD, if there is one.
Everyone watching gets disconnected at once. They come back when the player reconnects or when they reload, and the concurrent viewer count restarts from nothing.
Then there is the gap itself. Twitch publishes no figure for how long a restart takes.
Assume the gap is visible, and put it where it costs least.
- The past broadcast is truncated at the cut, and the rest starts a second file.
- Every viewer is disconnected at once, and the live counter restarts.
- The channel is out of the live directory for the length of the restart.
- The length of that restart is not published by Twitch, on any page.
What viewers see, and what the chat does.
The player stops and shows the offline screen or the hosting screen, depending on your settings. Some clients retry on their own, some wait for a reload.
Chat stays readable, because the chat room does not close with the broadcast. Messages sent during the gap are delivered, and moderation keeps working.
A poll or a prediction open at that moment is the exception. It resolves against a broadcast that has already ended, which is how a vote loses its result.
That is the part a 24/7 channel cannot shrug off: the audience is there at all hours, so the cut always lands on somebody.
Does the restart fire a go-live notification?
Twitch does not document this. There is no page describing whether a reconnect after the cap counts as a new go-live for notification purposes.
A reconnect creates a new broadcast, and the go-live notification has been seen firing again, which followers read as a second alert for a channel that never really stopped.
Fast reconnects often appear to be treated as a continuation instead, on a handful of channels.
Plan for the noisy case. A restart once or twice a day is defensible; one every hour turns your followers' notification list into a reason to mute you.
When will your current broadcast be cut?
Enter when the broadcast started. Computed in your browser, in your own timezone, sent nowhere.
Twitch cuts at 48 hours
Saturday, October 24, 2026 at 4:38 AM
Time left 1d 23h 59min 31s
Recommended voluntary cut, at 12 hours
Thursday, October 22, 2026 at 4:38 PM
The maximum broadcast length is 48 hours. This cannot be changed. Reconnection behavior may depend on encoder used.
Cron line for a restart at that cadence
38 4,16 * * * /usr/local/bin/twitch-restart.sh The 48-hour cap is from the Twitch Broadcast Guidelines. The 12-hour cut is the VOD247 default, not a Twitch rule.
Why reconnecting on failure is not enough.
The obvious plan is to let the cap hit and restart the encoder. It works for one machine streaming a game. It does not work for a channel that replays an archive.
The cut lands mid-VOD. A viewer who arrived twenty minutes ago loses the rest of the file, and the archived copy of that broadcast ends mid-sentence.
Between the cut and the reconnect, the channel is black. Whatever the restart costs, it is paid at whatever hour the cap happens to fall.
The channel also leaves the directory during that gap. Being listed while offline is the whole point of running 24/7, and the gap gives it back.
Then there is the chat. If a vote for the next VOD is open when the encoder dies, the bot announces a result for a broadcast that no longer exists.
- A cut lands inside a file, so the VOD is truncated and the viewer loses the ending.
- The screen is black for as long as the restart takes.
- The channel drops out of the live directory during the gap.
- A vote in progress resolves against a stream that has already ended.
Plan the cut instead: three ways.
The fix is to stop treating the reconnection as a failure. Pick the moment yourself, far below the cap, at a boundary you control.
The boundary is the gap between two files. Playback is a queue, so there is a point every few hours where nothing is mid-frame.
The rule is one comparison, made before starting each item. Recycle now if the session age, plus the next item's duration, plus a margin, would pass the budget.
The budget in VOD247 defaults to 12 hours, well under the 48-hour cap. The margin absorbs the recycle itself and any clock drift.
There is one deliberate exception. If a single item is longer than the whole budget, recycling before it buys nothing, so it plays and the session overshoots.
That exception is a choice: overshooting a soft 12-hour budget is cheap, and cutting a VOD in half is not. The hard cap stays far away either way.
The reference channel zerator_247 was observed running sessions of about 12.7 hours. That is the shape a planned recycle produces.
Three ways to get there, from the cheapest to the most precise.
- Compare before each item: session age + next duration + margin > budget.
- Budget defaults to 12 hours, against a 48-hour Twitch cap.
- Recycle only at a boundary between two files, never mid-file.
- An item longer than the budget plays anyway, and the session overshoots on purpose.
OBS alone, on a schedule.
OBS can stop and start the stream on a fixed schedule, well under 48 hours, but a restart on the clock lands wherever playback happens to be and cuts whatever is on air.
The script behind that line is two obs-websocket calls, built into OBS since version 28: StopStream, a short pause, then StartStream.
- Cron, twice a day, calibrated on your start time: 37 2,14 * * * /usr/local/bin/twitch-restart.sh
A restart that knows the playlist.
A restart that waits for the current file to finish cuts nothing. It decides between two videos, then reconnects before the next one starts.
The steps below are the minimum, and the last one is the easiest to forget: the vote bot has to be told the session changed.
- Know how long the current session has been running.
- Know the length of the next video before playing it.
- Apply the comparison: session age + duration + margin against your budget.
- If it passes, reconnect before the next video starts, never during one.
- Tell the chat bot the session changed, and let any open vote keep running on the VOD clock.
- Log every recycle with the session age, so a session that never recycles is visible.
Server-side playout, cut between files.
The third way is to run the decision inside the playout itself, where the queue, the clock and the vote already live. That is what VOD247 does, and the rule is the comparison above.
A planned recycle is a stop and an immediate restart, taken between two files. The worst case is a few seconds of black between two VODs instead of inside one.
The vote cycle survives it because it is keyed on the item on air, not on the connection. Requests open 20 minutes before the end of the VOD, the poll opens at 10 and closes at 5.
The session underneath can be recycled without touching any of that. The bot never announces a result for a broadcast that ended under it.
How long can you stream on other platforms.
Twitch is the strict one here, and the only one that writes its ceiling as a flat sentence. The rest is less tidy, which makes a comparison worth reading and worth dating.
Read the list as of the date below, then check it yourself before building anything on it. These are other companies' pages, and they change without notice.
- Twitch: 48 hours per broadcast, written in the Broadcast Guidelines, not changeable.
- YouTube Live: no documented cap on broadcast length for verified channels.
- Kick: no documented cap on broadcast length.
- Facebook Live: 8 hours per broadcast for a continuous live video.
- All four as published on 2026-09-14. Verify before you plan around any of them.
The checklist.
Run this list against whatever is publishing your channel today. Anything unchecked is a cut waiting for an hour when nobody is watching the dashboard.
- Your budget is well under 48 hours, and written down somewhere.
- The restart happens at a file boundary, decided per item, not on a clock.
- The next file duration is known before the decision, not guessed.
- The player does not stall at the seam between two files.
- A file longer than the budget has a defined behaviour, and it is not a mid-file cut.
- The vote cycle is keyed on the VOD on air, not on the connection.
- Every recycle is logged, with the session age at the moment it fired.