In OBS Studio, open Settings → Advanced, enable Automatically Reconnect, then choose a Retry Delay and Maximum Retries. The delay is the starting wait, not a fixed interval: OBS doubles the wait after each retry.
There is no single reconnect delay that suits every Indian broadband connection or every 24/7 YouTube loop. Set it in light of the interruptions you actually see, the time your channel can tolerate being offline, and tests on your own setup; retries cannot repair an unreliable connection.
Open OBS Advanced settings
In OBS Studio, open Settings and select Advanced from the left-hand list. The reconnect controls are in the Network area. Depending on the OBS version and window size, you may need to scroll within the page to find them. The labels to look for are Automatically Reconnect, Retry Delay, and Maximum Retries.
Make changes while the stream is stopped, then select Apply or OK. If you cannot find the controls, check the version of OBS you have installed and its current interface rather than relying on an old screenshot. OBS's output reference documents the reconnect behaviour, though the exact presentation in the desktop settings window can change.
These settings apply to OBS's streaming output. They are not the same as restarting OBS after a computer crash, restarting a video playlist, or asking YouTube to resume a broadcast. If you are deciding whether OBS is the right tool for a long-running loop, compare the operational choices in a guide to continuous streaming with FFmpeg. That is a different approach, with different configuration and failure points.
Before changing anything, note the current values or take a screenshot. That gives you a way back if a test behaves worse, and it makes later comparisons meaningful. Also record what you actually observe: the time of a dropout, whether the OBS output reconnects, and whether YouTube continues to show the live event. A setting is only useful if you know which part of the path it affects.
Enable Automatically Reconnect
Tick Automatically Reconnect to tell OBS to try connecting its output again if the connection to the streaming service is interrupted. Without this option enabled, the output will not use the retry behaviour configured by the other controls. Enabling it is a reasonable starting point for an unattended loop, but it does not make a weak network stable.
OBS describes dropped frames and intermittent disconnections as possible signs of a network problem between your computer and the remote ingest server. Causes can include an unstable connection or a bitrate that the connection cannot sustain. Its stream connection troubleshooting guide recommends diagnosing those conditions rather than assuming reconnect attempts will solve them.
Watch OBS's output status and dropped-frame indicators when problems occur. If drops are frequent, first ask whether the connection can sustain the selected stream settings and whether the connection itself is stable. A reconnect may restore a session after a brief interruption, but it cannot make an ISP outage end sooner or make an unreachable YouTube ingest endpoint available.
For a 24/7 loop, distinguish a brief interruption from a recurring pattern. If the connection drops at similar times each evening, for example, record the times and check whether other devices or services have trouble then. A retry setting can determine how OBS responds after a drop; it will not explain why the drop happened. A more general guide to creating a 24/7 YouTube channel can help you think through the other parts of an always-on operation, including what you need to monitor.
Set Retry Delay and Maximum Retries
Retry Delay sets the initial number of seconds OBS waits before its first reconnect attempt. Maximum Retries limits how many attempts OBS will make. The delay does not set the spacing for every attempt, because OBS increases the wait as attempts continue; the next section explains what that means in practice.
There is no official value for Indian broadband as a whole. A connection in one home or business may behave differently from another, and the relevant evidence is your own upload stability and interruption pattern. Start by deciding how long a short outage can last before the channel's interruption is unacceptable, then test a setting that gives OBS a chance to recover without assuming it can wait indefinitely.
| Choice | What it changes | Trade-off to consider |
|---|---|---|
| Shorter starting delay | OBS begins its retry sequence sooner | It does not make the line recover; subsequent waits still increase |
| Longer starting delay | The first attempt happens later | Recovery from a brief interruption can take longer |
| Lower maximum retries | OBS makes fewer attempts before stopping | A longer outage may outlast the retry sequence |
| Higher maximum retries | OBS can keep trying through more attempts | Later attempts are spaced increasingly far apart |
The table describes behaviours, not a recommended preset. Use the controls available in your installed version and avoid choosing a maximum solely because it looks large. Since waits grow, more attempts do not mean repeated attempts at the same short interval. Consider the outage window you are prepared to wait through and what you can do if it lasts longer.
YouTube recommends leaving outbound bandwidth headroom for a stream. Its streaming tips give guidance for the connection and stream setup; use the current official page when planning. Measure upload capacity rather than relying on download speed alone, and remember that a speed test is a snapshot, not proof that capacity will remain steady overnight. If you use a backup stream, it also uses outbound bandwidth.
Choose bitrate and video settings for the upload you can sustain, not for the fastest result from a single test. YouTube's encoder settings and bitrate guidance provides recommendations by output dimensions and other settings. Those tables are platform guidance, not a claim about what any particular Indian broadband connection can maintain. If your loop is primarily audio, the considerations differ from a high-resolution video loop; a guide to streaming audio on YouTube may help you consider that format.
Understand how retry waits increase
OBS's retry delay is the starting wait. The wait doubles on each successive retry, rather than remaining at the value shown in the box. For example, if you enter a hypothetical starting delay of 5 seconds, the sequence of waits would begin at 5 seconds, then 10, then 20, then 40. This example illustrates the doubling behaviour only; it is not a recommended setting for your connection.
That pattern matters when you choose a retry count. Later attempts happen farther apart, so the total time covered by a sequence grows quickly. A higher maximum can allow attempts over a longer outage, but does not mean OBS will keep checking every few seconds. A lower starting delay makes the first wait shorter; it does not hold all later waits short.
Think of the controls as two parts of one policy: the initial pause and the number of attempts. If a brief dropout usually ends quickly, an early first attempt may be useful to test. If interruptions last longer, the sequence's later waits and the maximum count matter too. Neither choice changes the reliability of the underlying connection, and no setting guarantees that YouTube will keep the broadcast active through every interruption.
The time to recovery also depends on when the connection comes back and whether OBS can reach the ingest service at the next attempt. If the line returns just after an attempt, OBS may wait through the next interval. If the line remains down, there is nothing for OBS to reconnect to. This is why looking only at the initial delay can create an unrealistic expectation about the full retry window.
When you review an event log or make notes during a test, distinguish the time the network returns from the time the output is restored. Those are separate events. The retry sequence may be behaving exactly as configured even if the visible recovery seems slow, while a repeated failure at the same point may call for a network or stream configuration diagnosis instead.
Know what zero retries means
A Maximum Retries value of zero disables automatic reconnecting, according to OBS's output documentation. It does not mean “retry immediately” or “keep trying without a limit”. Check the setting carefully if you intend OBS to make attempts after an output drop.
A finite retry count also means the retry sequence can end while an outage is still in progress. Do not treat a positive count as an unlimited safety net. For an unattended channel, decide what you will do if the maximum is reached: can someone check the computer, is there a notification or monitoring process, and is there a way to start the output again? A good operational plan accounts for what happens after the automatic behaviour stops.
Also separate output reconnecting from restarting an application or computer. OBS's reconnect control handles the streaming output; it is not a general recovery mechanism for a frozen operating system, a crashed OBS process, or a power cut. If your workflow depends on process-level recovery, an article on restarting an FFmpeg stream after a process crash covers a distinct problem and should not be mistaken for an OBS setting guide.
Keep the YouTube stream key private. YouTube describes a stream key as the information an encoder uses to send a feed, and its live stream settings guidance explains managing those settings, including resetting a compromised key. If you reset it, update OBS with the new key before the next test; a reconnect setting cannot compensate for credentials that no longer match.
Test reconnect behaviour before the loop
Do not wait for a real overnight failure to learn how your setup behaves. Test before relying on the configuration for a long unattended loop. Use a short, controlled test stream or an appropriate private/unlisted test arrangement, and make sure you understand the audience and visibility implications before changing the broadcast's privacy settings. Avoid deliberately interrupting a public event that viewers expect to remain live.
Observe both ends of the path: OBS's output state and YouTube's live status or stream health. Note what happens when the output is interrupted and restored, how long recovery takes, and whether the retry sequence stops. YouTube recommends testing before going live and monitoring stream health; use its current encoder and stream-health guidance alongside what OBS reports. A successful test is evidence about that test, not a promise about a later ISP or ingest interruption.
If your computer is on Wi-Fi, compare with a wired connection when practical. OBS recommends wired networking because Wi-Fi may be unstable for streaming. An Ethernet cable can help avoid some local wireless issues if the router and computer have compatible ports, but it cannot fix an ISP outage or a problem at YouTube's ingest service. Change one condition at a time so you can tell whether the result came from the network, stream settings, or retry configuration.
If the line remains troublesome, follow a diagnostic sequence rather than repeatedly shortening the delay. Check whether the bitrate is stable for the available upload, whether VPN or security software is interfering, and whether drivers or network-optimisation utilities are involved. OBS notes that dynamic bitrate may reduce dropped frames when the connection cannot keep up, but it does not fix the cause and can lower quality. Choose any adjustment with that trade-off in mind.
For a channel whose content is a recorded loop, also test the content workflow separately from the connection. Confirm that the source continues playing, audio remains in sync, and OBS is still responsive. A video ending or a local computer sleep setting is not a broadband dropout, so changing reconnect behaviour would not address it. If an always-on workflow is difficult to supervise because the computer must remain available, StreamNeo removes the specific burden of keeping your own computer running by turning an uploaded video into a 24/7 YouTube live stream that you can monitor without leaving that computer on.
After testing, keep a short record of the OBS version, chosen delay and retry count, connection type, stream settings, and observed recovery. Revisit those notes if you change router, ISP plan, computer, or output settings. Do not treat one clean night as a permanent verdict; the purpose is to learn how the current setup responds and to know what to check when it does not.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Where is Automatically Reconnect in OBS?
Open Settings → Advanced and find the network controls. Enable Automatically Reconnect, then configure Retry Delay and Maximum Retries. The layout can vary slightly by version, so use the labels rather than relying on a particular screenshot.
Does Retry Delay stay the same for every attempt?
No. It is the starting wait, and OBS doubles the wait on each retry. A five-second example would progress to ten and then twenty seconds; those numbers illustrate the behaviour, not a recommendation.
What does Maximum Retries set to zero do?
OBS documents zero as disabling automatic reconnecting. It does not mean unlimited attempts or an immediate retry. If you want OBS to retry after a drop, check that reconnecting is enabled and the maximum is not zero.
What should I use for Indian broadband?
There is no universal value for Indian broadband. Choose based on the interruption pattern you observe, the time you can tolerate a failed output, and controlled testing on your setup. Retries can help OBS respond to a temporary interruption, but they do not repair an unstable line or guarantee an uninterrupted broadcast.