To restart a 24/7 recorded lecture stream after OBS crashes, use a monitor that runs outside OBS to detect that its process has exited and launch it again. OBS launch options can select the intended scene collection and profile and start streaming or recording, but they cannot restore missing credentials, files, network access or configuration.
On Windows, Task Scheduler can help start the monitor at system startup or run a script, but it is not, by itself, an OBS crash watcher. The recovery pattern below separates detection from relaunch, sets the right working directory, and tests whether your particular OBS installation can resume without an interactive prompt.
Why OBS needs an external monitor
An OBS script or WebSocket client can control a running OBS instance. If OBS itself exits, however, its own scripts and controls are no longer available to notice the failure and start a replacement process. Recovery therefore needs a second process outside OBS: a supervisor, service wrapper or script that remains active while OBS is not.
Do not confuse process recovery with network reconnect. OBS may be able to reconnect while it remains open and loses its streaming connection. If OBS crashes and closes, that reconnect behaviour cannot relaunch the application. The distinction matters when diagnosing an interrupted lecture stream: a disconnected broadcast and an exited encoder require different responses.
The supervisor's job is narrow. It checks whether the expected OBS process is present; after an exit, it waits briefly, checks again to avoid starting a duplicate, and then launches OBS with the intended options. It should also log what it saw and what it attempted. This is a cautious recovery pattern, not a promise that a stream will resume: a computer, network, account, file or endpoint problem can prevent the new instance from going live.
If you are still deciding whether OBS is the right tool for a continuous loop, the practical differences in OBS and FFmpeg for looping videos are worth reviewing. A supervised OBS setup makes sense when you need its scenes and sources; another workflow may suit a simple file loop better.
Check OBS launch options and configuration
OBS documents launch parameters for choosing a scene collection, profile and scene, and for starting streaming or recording when a new process opens. For example, an invocation might include --collection "Lecture" --profile "24-7" --startstreaming. If your intended output is local recording rather than YouTube, --startrecording is the relevant output option. These are examples: use the actual names from your OBS installation and check the OBS launch parameters documentation against the version you have installed.
The flags describe what OBS should attempt at startup. They do not create or repair the configuration they point to. Before automating a relaunch, open OBS normally and confirm that the selected collection and profile load correctly, the expected scene is present, and the output settings still point to the right destination. If streaming and local recording are both required, establish and test that combination manually first rather than assuming a single flag will reproduce a multi-output workflow.
Review the dependencies of the lecture scene as well. A media source can refer to a file that was moved; a network source may not be reachable at boot; a capture device may not be ready; a plugin may prompt or fail to load. Confirm the streaming credentials remain available to the same Windows user account under which the monitor will run. The launch options select and start a configured setup; they do not supply missing credentials or make an unavailable source available.
If scene complexity is the reason a restart is hard to validate, see how to manage multiple scenes in OBS. Keep a known-good lecture scene and profile, and avoid changing them while you are still proving the recovery path.
Create a process check and restart action
A process monitor needs two distinct actions: detect that OBS is gone, and start the intended OBS command. Task Scheduler provides triggers and can run an executable, script or batch file; Microsoft documents triggers such as ONSTART and ONEVENT in its schtasks create reference. That documentation does not supply an OBS-specific process-exit watcher. You must pair a scheduled launch with a separate supervisor implementation, or use a process-monitoring tool suitable for your Windows environment.
Keep the check conservative. It should look for the expected OBS process, allow a short settling interval after detecting an exit, then check that no instance has returned before launching another. This helps avoid creating duplicate OBS windows if a slow shutdown or manual restart overlaps with detection. Avoid a tight loop that repeatedly relaunches after an immediate failure: use a delay, record each attempt, and set a sensible limit or alert path so a broken configuration does not produce an endless restart cycle.
Run the monitor in the Windows user and session context that can access OBS's configuration, media files, credentials, devices and desktop. A service running in a different account or non-interactive session may not see the same settings or sources. Test this before relying on it. The objective is not to add complexity for its own sake; it is to make the restart command repeatable and visible when it fails.
OBS scripts and WebSocket are useful for controlling an open application, but they are not substitutes for the external process check. OBS describes its extension routes in the developer guide. Once the process has terminated, a control connection to that process cannot be the dependable mechanism that starts it again.
Set up the Windows scheduled task
Use Task Scheduler to start your supervisor when Windows starts, or to run a script at an appropriate event. The scheduled action should start the monitor, not merely start OBS once and assume it will notice a later crash. Configure the task to run under the account that has the working OBS profile and access to the lecture assets. Whether to run only when that user is logged on depends on how your scene uses desktop capture, devices and other session-bound resources; validate the choice on the actual machine.
Task Scheduler can start a program or script, but the trigger alone does not define how to detect OBS exiting. A process-exit event trigger may be part of a design only if you have verified that your particular event source and task configuration really detect the failure you care about. Do not treat ONSTART as a crash trigger: it runs at system startup, not whenever OBS closes. In many setups the simpler pattern is an always-running external supervisor launched at startup, with that supervisor checking OBS process state.
Keep the task's restart behaviour and the supervisor's restart behaviour from competing. If both independently launch OBS, they can race and create duplicate instances. Document which component owns detection, which owns launch, where its logs go, and how you will be notified if the task itself does not start. Task history can help confirm the scheduled action ran, but it does not prove the resulting OBS session streamed correctly.
For a recorded course that must keep playing after a local computer is shut down, the local scheduled-task design has a different limitation: the machine must be on for OBS to run. The considerations in keeping OBS streaming after shutting down your computer help distinguish a crash-restart plan from moving the continuous workload off that computer.
Set the OBS working directory
Set the scheduled launch's working directory to the folder containing obs64.exe. OBS specifically calls out the Windows working directory for scheduled or automated launches in its launch-parameters guidance. If a task launches OBS from an unexpected directory, relative paths and application behaviour may differ from a launch made through the usual shortcut.
In Task Scheduler's action settings, the executable path belongs in the program field, its launch arguments in the arguments field, and the OBS executable's containing folder in “Start in”. If a script performs the launch, make its working-directory choice explicit rather than relying on whichever directory happened to be active when the script began. Check that paths with spaces are quoted correctly, and use the same executable and configuration that you tested interactively.
The working directory is not a substitute for checking source paths. A scene may use an absolute path to a video, a mapped drive, a network share or a plugin-specific resource. Confirm those are available after reboot and under the scheduled account. Mapped drives, in particular, can differ by user session; a successful launch in your desktop session does not prove the task can resolve the same location.
Test crash detection and stream recovery
Test in a maintenance window, not during a lecture that viewers depend on. First run the supervisor and OBS normally, then close OBS cleanly and check whether the monitor observes the exit and starts the intended command. Next, arrange a controlled unexpected termination and repeat the check. A clean close and a crash are not necessarily handled identically: OBS may show a recovery or crash dialog on its next launch, and plugins or scripts may behave differently.
Observe the relaunch on screen during initial tests. Verify the right collection, profile and scene are active, the intended output begins, and any local recording file is being written where expected. Confirm the YouTube live stream actually appears in the channel's live controls rather than treating the presence of an OBS process as proof of a successful broadcast. Check logs and inspect any prompts that would require a person to dismiss them.
Test a temporary network interruption separately. It exercises OBS's connection-recovery behaviour while the program remains open; it does not establish that the external monitor can recover from a process exit. Likewise, testing a crash does not prove recovery from an unavailable network, expired or inaccessible credentials, a missing lecture file, or a streaming endpoint problem. Record what each test covered and what it did not.
Do not make your first test during a live class or leave a newly configured task unattended overnight before observing a full test cycle. If a crash dialog offers Safe Mode, note that this can disable third-party plugins, scripts and WebSockets; a scene that depends on one of these may not behave as expected in that mode. Review the installed release's behaviour and test the actual workflow, since prompts and plugin effects can vary.
Monitor for repeated failures
A relaunch can fail repeatedly for the same underlying reason. If OBS exits soon after starting, the monitor may keep trying to revive a process that cannot remain open. Retain timestamps and error output, and make repeated attempts visible through a notification or a log you will actually review. Set a pause or stop condition after repeated failures so that a persistent fault does not become an invisible loop.
When investigating, compare the last known-good run with the failed relaunch. Check whether the profile or scene collection changed, a file path moved, a plugin updated, the user account changed, or the network destination became unavailable. OBS logs can help narrow down what occurred, but they cannot show every external cause. Check Windows task history as well as OBS's own logs so you can distinguish “the task did not run” from “OBS started and then failed”.
For a channel whose availability matters, a check from another device or location can reveal that the broadcast is absent even when the local machine appears healthy. Local process supervision cannot repair an internet outage, power failure or inaccessible YouTube endpoint. A UPS addresses some power interruptions, not an OBS process crash, and does not replace a process monitor.
A cloud-based file-to-live workflow may remove the specific dependency on keeping your own computer running; StreamNeo turns an uploaded video into a YouTube live stream, so you do not need to keep OBS open on that local machine for that workflow. It is YouTube-only, and it does not make a missing source file, credential or channel configuration issue disappear, so check the setup requirements that apply to your broadcast.
If the lecture is a fixed video rather than a scene-based production, turning a podcast into a 24/7 YouTube live stream is another file-looping workflow to consider. Choose based on what the programme needs: live scene changes and inputs favour an OBS production; a stable recorded loop may not need all of those controls.
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
Can OBS restart itself after it crashes?
Not reliably through an OBS script running inside the process that has already exited. Use an external monitor to detect that OBS is gone and launch a new instance with the required startup options. Test that monitor and the new instance on your Windows account before relying on them.
Does OBS automatically start streaming when it opens?
OBS provides a --startstreaming launch parameter, and --startrecording for local recording. The intended collection, profile, credentials, sources and network still need to be available and configured; the parameter does not repair a missing dependency.
Can Task Scheduler restart OBS after every crash?
Task Scheduler can start a program or script at configured triggers, but its documented startup trigger is not an OBS process-exit watcher. Pair it with a process supervisor or a verified event-based design, and make sure only one component owns relaunching OBS.
Will a restart preserve my lecture stream without interruption?
No. A restarted OBS process may take time to open or may fail to stream because of a prompt, missing file, unavailable network, credential issue or other dependency. Test recovery in a maintenance window and monitor the actual broadcast, rather than assuming that a running process means viewers can see it.