If OBS loses its connection but stays open, its automatic reconnect setting can retry the output. If OBS itself exits or crashes, reconnect cannot reopen it: you need an operating-system supervisor or scheduled mechanism to relaunch OBS, then a tested YouTube broadcast configuration.
Treat recovery as a chain, not a single checkbox. A supervisor can start OBS again, but it cannot repair a failed computer, network, stream key or media source, and it cannot guarantee YouTube will accept the restarted feed.
First identify what stopped
Before changing settings, establish whether OBS is still running. A disconnected output and an exited application can look similar from YouTube’s side: the incoming picture freezes or disappears, and the broadcast may stop or change status. On the computer, however, the recovery paths are different.
If the OBS window remains open, check its status bar and the stream controls. An output that reports a dropped connection while the application remains responsive is a connection failure. OBS may be able to retry that output without restarting the application. If the window has vanished, Windows Task Manager or the equivalent process list shows no OBS process, or OBS has displayed a crash dialog, that is a process exit. An output setting inside an application that is no longer running cannot act on its own.
Also distinguish an OBS exit from a whole-machine failure. A reboot, power cut, sleep event, or lost network connection may cause the stream to stop without OBS being the original fault. Record what you observed and when: application still open, process gone, computer restarted, or network unavailable. This basic log helps you choose a useful recovery mechanism rather than repeatedly changing unrelated stream settings.
The YouTube control room offers another clue, but it is not a complete diagnosis. Check whether YouTube still sees encoder input and note the broadcast status. A missing input can follow a local crash, a network interruption, or a stopped encoder. Use the computer’s state to identify the layer that failed, then use YouTube’s status to verify what happened at the receiving end.
If you are setting up the stream key at the same time, follow the steps in creating a reusable YouTube stream key. Keep the key private, and confirm that OBS is using the intended stream rather than assuming a reconnect or relaunch will correct a wrong key.
What OBS automatic reconnect can do
OBS automatic reconnect is intended for an output connection that has failed while OBS remains in control of it. It can retry sending the stream after a temporary drop, such as a brief network interruption. In OBS output settings, enable the reconnect option and select a retry delay and maximum retry count that make sense for your connection and the kind of interruption you expect.
The OBS Project’s output reference describes reconnect settings including retry count and retry interval. The retry interval increases between attempts; a retry count of zero disables reconnect. See the OBS output API reference for the documented behaviour. The exact controls and their location can vary with the OBS version and output type, so confirm what your installed release exposes rather than relying on a screenshot for another version.
Think of reconnect as a limited response to an output problem, not a promise that every outage will resolve. A poor connection may persist, a retry limit may be reached, or the stream key or destination may be invalid. You can choose a longer delay to avoid an aggressive burst of attempts, but a longer delay also means more time before a recovered connection is tried. Choose settings with the actual connection in mind and test them under controlled conditions.
Reconnect also does not restart the media or restore every source fault. If the video file has ended, a source has failed, or the OBS scene is wrong, the output might connect while the content remains incorrect. For a looped programme, verify that the source itself continues to play as intended, not merely that OBS reports an active connection. The practical distinction is simple: reconnect repairs a connection attempt made by a running OBS instance; it does not diagnose or repair the rest of the production chain.
Why reconnect cannot relaunch a crashed process
A process crash ends the application that owned the output and its reconnect settings. Once OBS has exited, there is no active OBS process to count retries, open a connection, or read an output configuration. A separate mechanism must notice that the process is gone and start OBS again.
That mechanism could be an operating-system task or a process supervisor, depending on your computer and how you run OBS. It should be configured to launch the same OBS installation and the intended profile and scene collection. It may then request streaming on launch, but a successful application launch is not proof that the broadcast resumed. OBS may encounter a missing source, ask for attention, start in the wrong user session, or fail to reach YouTube.
This is why a process supervisor and OBS reconnect solve different problems. The supervisor addresses an absent process. OBS reconnect addresses an output interruption while the process remains alive. They can be used together, but neither replaces the other, and neither repairs a root cause such as an unstable router, overheating computer, expired credentials, or unavailable media file.
Do not configure a rapid, unlimited restart loop. If OBS crashes repeatedly because a source or configuration is broken, immediately launching it again can reproduce the same failure without giving you useful information. Add a pause between attempts where your system allows it, and arrange a notification or log so you can see repeated failures. Keep a manual recovery path: check the computer, inspect OBS, and confirm the YouTube input rather than assuming a restart is enough.
Configure a supervisor or scheduled relaunch
There is no single watchdog recipe that fits every operating system, OBS release and desktop setup. The official OBS guidance documents launch parameters, but does not prescribe a universal crash-monitoring product or exact supervisor configuration. Use the tools appropriate to your operating system, and take care that the restart runs in the same account and desktop session as the OBS instance you normally use.
A scheduled task can be suitable for starting OBS at a planned time, such as after a computer reboot. It is not automatically a crash monitor: a task that runs once at login will not necessarily notice a later OBS exit. A process supervisor, or a scheduled mechanism explicitly set up to detect and respond to process exit, is needed for that case. Confirm its trigger semantics rather than assuming that “start at login” means “restart after a crash”.
On Windows, OBS’s launch guidance says automated or scheduled launches should set the working directory to the folder containing obs64.exe. This matters because launching an executable from an unexpected working directory can produce different behaviour from opening OBS normally. Use the path for your own installation and follow the current OBS launch parameters guidance.
Make the launch deterministic. Specify the profile and scene collection if you use more than one, and check that the target account can access all media files and sources. Test whether OBS launches visibly in the expected desktop session. If the mechanism starts the process in a background session without access to the expected display or user resources, it may not behave as a manually opened OBS window would.
Set a sensible delay before retrying and decide how you will notice repeated failures. A persistent crash should lead to an alert or a human check, not an endless sequence of launches. Keep the supervisor’s logs, and make a short note of the time of each failure, whether the OBS process returned, and whether YouTube received video and audio. That evidence makes it easier to separate a broken relaunch command from a stream or media problem.
If the computer itself needs to resume the loop after restarting, that is a separate configuration question from an OBS process crash. The walkthrough on starting a YouTube radio stream after a reboot is relevant to the boot-time part of the chain. Do not infer from it that a mechanism which starts OBS after boot also monitors later crashes; those need separate triggers and tests.
Use OBS’s start-streaming launch parameter
OBS documents --startstreaming as a launch parameter. When OBS starts with this parameter, it is asked to begin streaming rather than waiting for you to press Start Streaming manually. It is useful in a relaunch command, but it does not create the process monitor: your operating-system mechanism still has to detect the exit and invoke OBS with the parameter.
OBS also documents launch parameters for choosing a profile and scene collection. Use those when a reliable restart depends on a particular stream layout or configuration. For example, a channel that has a “night loop” scene collection should make sure the relaunch opens that collection, not a temporary scene used for testing. Check the spelling and syntax in the current OBS documentation and test the exact command used by your supervisor.
A typical command conceptually combines the OBS executable with --startstreaming; profile or collection parameters can be added when needed. The exact quoting, paths and task fields depend on your installation and operating system, so avoid copying a command line blindly. On Windows, include the documented working-directory setting described above. If OBS opens but does not begin streaming, inspect the task’s launch arguments and the application’s own logs before changing YouTube settings.
Use the same OBS profile you have already tested manually. A relaunch can expose problems that a normal desktop session conceals, such as an unavailable media path or a source that requires interaction. If your loop depends on local files, use stable paths and confirm that the task account can read them. If the source is a playlist or capture device, verify it is still available after OBS is relaunched.
Some channels use FFmpeg or another encoder instead of OBS, and their failure behaviour is different. The article on FFmpeg stopping after one loop covers that separate source of trouble; do not apply an OBS process command to an encoder that is not running OBS.
Check YouTube’s broadcast start and stop behaviour
YouTube Live’s Auto-start and Auto-stop choices affect how a broadcast responds to encoder input. Review these settings for the particular live stream and stream key you are using. They do not launch OBS, and changing them cannot bring back a computer process that has crashed. They determine how YouTube treats a feed when an encoder starts or stops sending, subject to the configuration of that broadcast.
YouTube documents stream-key and live-stream controls in its Manage live stream settings help page. It notes that reusing stream settings also reuses Auto-start and Auto-stop selections, so check the actual stream configuration rather than assuming a new broadcast inherited the behaviour you want. The choices are not universal: a channel may want a broadcast to start when the encoder begins, while another may prefer to start and stop it manually.
Match the setting to your operating plan. If OBS is launched automatically and should drive the broadcast lifecycle, verify that the relevant Auto-start behaviour is enabled for the stream. If you need a manual review before the broadcast goes live, keep that workflow in mind when choosing settings. Similarly, decide whether an encoder stop should cause the broadcast to stop automatically or whether you want to manage the end of the event yourself. Review YouTube’s current guidance because interface labels and options may change.
Do not assume a fixed time window in which YouTube will hold a broadcast open or that every encoder restart will resume the same event. The outcome depends on the stream configuration and what YouTube sees. After a relaunch, check the live control room to confirm whether YouTube reports incoming encoder data, whether the broadcast is waiting or live, and whether the video and audio are correct.
For an always-on music or devotional channel, the broadcast lifecycle and the programme loop are separate concerns. A stream can be live while a source is silent or displaying the wrong scene. If you are planning multiple continuous programmes, the guide to separate 24/7 YouTube radio streams by mood may help you think through stream organisation, but it does not replace checking the start/stop behaviour of each broadcast.
Test the entire recovery path before relying on it
Do not wait for a real overnight failure to learn whether the recovery chain works. First test OBS’s ordinary connection recovery in a controlled session, then test the process-exit path separately. The second test should verify that your supervisor detects an OBS exit, starts the expected executable with the intended arguments, and produces the stream you expect. Do not conduct a disruptive test during a broadcast that viewers depend on.
A useful test has observable checkpoints. Before triggering it, note the selected OBS profile and scene collection, confirm the YouTube stream key is correct, and verify that the stream is in a state suitable for a test. After the simulated interruption, check that the OBS process is present, the expected scene and source are active, and audio and motion are being sent. In YouTube Studio, check for encoder input and the intended broadcast status. A process that merely reappears in Task Manager is only one checkpoint, not a successful recovery.
OBS’s Quick Start Guide recommends testing the setup for a few minutes, while YouTube recommends testing before going live and monitoring stream health during the event. See the OBS Quick Start Guide and YouTube’s encoder settings and stream health guidance. Use representative motion and audio in your own test so you can spot a frozen image, muted source or unexpected scene. The aim is to verify each layer, not to infer a reliability rate from a short test.
Write down what happened: whether OBS stayed open, whether the supervisor relaunched it, how long the visible recovery took, and what YouTube reported. Repeat only enough to confirm the intended sequence and correct any discovered configuration issue. A test cannot prove that every future failure will recover; it can show whether the current setup handles the specific failure you tested.
Keep a manual fallback for cases the automation cannot fix. If the computer is off, the network has no route to YouTube, the stream key is invalid, or the source file is missing, a process restart may simply repeat the failure. If a crash recurs, stop automatic attempts, inspect the cause, and restore the broadcast deliberately. For a continuous channel, a managed approach can remove the need to keep a personal computer running or manually reopen the application after a local crash: StreamNeo turns an uploaded video into a YouTube live stream that runs with your computer switched off and is monitored and restarted automatically if it drops.
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
Does OBS automatic reconnect restart OBS after a crash?
No. Automatic reconnect retries an output connection while OBS is still running. If the process exits, you need a separate operating-system supervisor or scheduled mechanism to launch OBS again.
What does --startstreaming do?
It is an OBS launch parameter that requests streaming when OBS starts. It does not monitor for a crash or guarantee that YouTube will accept the resumed feed, so test it with the exact command and account context you plan to use.
Should YouTube Auto-start and Auto-stop be enabled?
That depends on whether you want encoder activity to control the broadcast lifecycle or prefer to start and stop it manually. Check the settings for the specific stream and key, and verify the result in YouTube Studio during a controlled test.
Will a supervisor guarantee my 24/7 stream recovers?
No. It can relaunch OBS after a process exit, but it cannot repair an unavailable computer, network, invalid key, or broken source. Test the complete path and keep a way to inspect and recover the stream manually.