A Windows VPS can reopen OBS and start its stream after a reboot if you configure Windows to launch OBS with the --startstreaming argument. That is different from OBS automatic reconnect, which can help with a dropped connection only while OBS is still running.
A successful encoder connection is not proof that the intended YouTube broadcast is live to viewers. First verify the stream manually, then configure startup and test the complete path from Windows boot to YouTube’s viewer-facing status.
Verify OBS and YouTube manually first
Do not begin by automating a setup you have not watched work once. In OBS, confirm the scene collection, profile, output settings and YouTube destination you intend to use. Then start a manual stream and check its state in both OBS and YouTube Live Control Room.
If you use a scheduled broadcast, make sure you have selected the correct event. YouTube’s broadcast settings include controls such as auto-start and auto-stop; the selected event and those settings affect what happens when an encoder sends video. Consult YouTube’s current live stream settings guidance rather than assuming a previous event or an older interface behaves the same way.
The viewer-facing check matters. OBS can report that it is sending data while YouTube is waiting for a broadcast to start, showing a different scheduled event, or otherwise not presenting the stream you expect. Open the intended Live Control Room event and, where practical, its public watch page. Confirm the channel, title, video and live state before treating the manual test as successful.
Treat the stream key as a credential. Do not put it in a public screenshot, script shared with others or support message. YouTube Help explains how to manage stream settings and keys; if a key is exposed, use the current controls to replace it and update OBS. You can also review how bitrate and frame rate relate to YouTube streaming before settling on output settings, but a suitable bitrate does not replace a full broadcast test.
Save the profile and scene collection
OBS keeps settings in profiles and scenes in scene collections. The profile contains streaming and output choices, while the scene collection holds the scenes and sources that make up the programme. Save both once the manual test is correct, and note their names so you can identify them after a reboot.
This is especially useful on a VPS where you might have created a test profile before the final one. A launch that opens OBS successfully can still use the wrong profile or scene collection. During a manual run, confirm the destination and visible content, then save any changes and close OBS normally before setting up automation.
Do not assume that Windows will preserve an interactive desktop exactly as you left it. If OBS starts under a different account, a different profile may be selected or the intended configuration may not be available. Use the same Windows account and OBS installation that you used for the verified manual test, and check what the VPS host does when it restarts the machine.
If the video itself comes from phone footage, investigate source issues separately from startup behaviour. For example, removing variable frame rate from phone videos before using OBS may help avoid a source problem that a reboot task cannot fix. Automation should reproduce a known-good stream, not conceal unresolved media or scene issues.
Add --startstreaming to the OBS launch
OBS documents --startstreaming as a launch parameter that starts streaming when OBS opens. Windows automation can therefore open OBS with this argument rather than merely opening the application and waiting for someone to press Start Streaming. Use the path to the executable actually installed on your VPS; do not copy a path from a tutorial that may use another drive or OBS installation.
A shortcut is a simple way to understand the command before creating a scheduled task. Its target should point to the OBS executable, followed by the argument. For example, if the executable is at C:\Program Files\obs-studio\bin\64bit\obs64.exe, the target would be:
"C:\Program Files\obs-studio\bin\64bit\obs64.exe" --startstreaming
This is an example path, not a claim about where OBS is installed on your VPS. Check the actual location in File Explorer or the shortcut used to open OBS. Keep the quotation marks around a path containing spaces, and place --startstreaming outside the closing quote.
The command requests that OBS begin streaming. It does not choose the correct YouTube scheduled event for you, guarantee that the network is ready, or confirm that viewers can see the intended broadcast. Those are separate checks. The OBS launch parameters documentation describes the argument and also calls out the working-directory requirement for automated Windows launches.
Configure Startup or Task Scheduler
There are two common ways to have Windows open OBS when you sign in or start the VPS: a Startup shortcut or a Task Scheduler task. A shortcut is easier to inspect and can suit a simple setup where an interactive login reliably occurs. Task Scheduler gives you more control over triggers and conditions, and is usually the more appropriate place to configure a repeatable boot action on a VPS.
| Approach | What it does | Main trade-off |
|---|---|---|
| Startup shortcut | Opens OBS when the relevant Windows account signs in | Depends on the account’s sign-in and Startup behaviour; fewer controls for timing and conditions |
| Task Scheduler | Runs OBS according to a configured trigger, with an argument and conditions | More settings to check, including account context and working directory |
| OBS automatic reconnect | Tries to restore a connection after a temporary network interruption while OBS remains open | Does not reopen OBS after Windows restarts or the OBS process closes |
For a Startup shortcut, place a shortcut to the correctly configured OBS launch in the Startup folder for the same Windows account used by the stream. Confirm that the shortcut target includes --startstreaming. Do not test only by clicking the shortcut while OBS is already open; close OBS first and check what happens in a fresh launch.
In Task Scheduler, create a task with a trigger appropriate to the way the VPS is operated, such as at system startup or at sign-in. Set the action to start the actual OBS executable and add --startstreaming in the arguments field. Choose the account and run conditions deliberately. A task that runs only when a particular user is logged on may not behave as expected if your host reboots unattended and nobody signs in; conversely, running in a non-interactive context can affect applications that expect a desktop session. Test the option you configure on that machine rather than assuming the labels guarantee the result.
Avoid creating a second startup mechanism before understanding the first. If both a Startup shortcut and a scheduled task launch OBS, a boot may produce two launch attempts or an unexpected already-running instance. Begin with one mechanism, record its settings, and add another only if a specific observed failure calls for it.
Set the task’s working directory
When you use Task Scheduler or another automated launch, set Start in to the folder containing obs64.exe. OBS explicitly requires the working directory for automated Windows launches. If the executable is in C:\Program Files\obs-studio\bin\64bit, use that folder as the working directory, without putting the executable filename in the Start in field.
This is not the same as the executable path. In Task Scheduler, the action has separate fields for Program/script, Add arguments, and Start in (optional). The first points to obs64.exe, the second contains --startstreaming, and the third points to the executable’s containing folder. Check each field for stray quotation marks or a path copied from another installation.
A correct target with a missing or incorrect working directory can behave differently under automation than when you launch OBS by hand. That is why it is worth recording all three values and testing the task itself. Do not infer success from a desktop shortcut unless the shortcut and scheduled task use the same executable, arguments and working context.
Distinguish reboot recovery from reconnect
OBS automatic reconnect and Windows reboot recovery solve different problems. If OBS is still open and its connection drops, OBS may try to reconnect. If Windows reboots, or OBS exits, there is no OBS process left to reconnect; Windows must start OBS again. The --startstreaming launch argument is useful in that second case only when a Windows startup mechanism actually launches the application.
You can decide which recovery path you need by identifying what failed. A transient dropped connection while OBS remains open points to the network path, ingest connection or output settings. OBS notes that dropped frames can indicate an unstable connection or bitrate that the connection cannot sustain; see its stream connection troubleshooting guidance. Repeatedly restarting OBS without checking those causes may bring the stream back briefly without addressing why it dropped.
If OBS has closed or Windows has restarted, focus on the startup trigger, account context, executable path, argument and working directory. If OBS is streaming but YouTube does not show the intended broadcast, check the scheduled event and its auto-start or auto-stop behaviour. A scheduled broadcast can have settings that affect whether incoming encoder data starts the viewer-facing event or whether the event ends when the encoder stops. Verify current options in Live Control Room because labels and behaviour can change.
A third situation is a network route that becomes usable only after Windows has started. A startup task may run before DNS or the route to YouTube is ready. OBS community discussions describe cases where a first attempt fails and a later retry is needed, but this is not a guarantee about every VPS. First observe what your host does during a reboot. If the issue is reproducible, consider a measured delay or connectivity-aware retry and test it; adding a watchdog without evidence adds complexity and another component to maintain.
For a channel that depends on a home or local connection rather than a VPS, the underlying route deserves the same attention: keeping an always-on YouTube stream running on an Indian broadband connection covers a different network context, but the distinction between a network interruption and a stopped encoder remains useful.
Test reboot recovery and YouTube broadcast status
Test during a maintenance window, not during a programme whose continuity matters. Warn anyone who may be watching or managing the channel, and ensure you can access the VPS if the task fails. A reboot test is a recommended procedure, not a promise that a particular host, Windows account or broadcast configuration will recover in a specific time.
After restarting, verify each stage in order:
- Windows completed startup and the expected account or task context is active.
- OBS opened from the intended installation, with the expected profile and scene collection.
- The OBS streaming indicator shows an active connection to the configured destination.
- Live Control Room shows the expected event receiving input and in the appropriate live state.
- The public watch page, where applicable, presents the intended stream rather than a waiting screen, stale event or different broadcast.
Do not stop at the third check. OBS’s local indicator tells you about the encoder connection; it does not prove that YouTube has started the intended broadcast for viewers. Confirm the title and content as well as the state. If the channel uses a scheduled event, make sure the automation is not feeding the wrong event or an old stream configuration.
If the test fails, change one thing at a time. If OBS did not open, inspect the trigger, account and executable path. If it opened without streaming, inspect the argument and the selected profile. If OBS connected but YouTube did not show the event, inspect Live Control Room selection and broadcast settings. If the connection dropped, investigate network readiness, route stability and bitrate before adding a restart loop.
Repeat the test after meaningful changes to Windows, OBS, the scheduled task, the stream key or YouTube event settings. Keep a short record of the task configuration and the result of the last observed reboot test. That record is more useful than assuming a task still behaves as it did before an update or account change.
If maintaining the machine, login and reboot tests is the pain you are trying to avoid, StreamNeo turns an uploaded video into a YouTube live stream that can run with your computer off; you provide the file and your YouTube stream key, and it monitors and restarts the broadcast if it drops. It is YouTube-only, so it does not replace OBS when you need live scene switching, capture sources or hands-on production control.
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 the stream after a Windows reboot?
No. Automatic reconnect can address a temporary connection loss while OBS is still running. After a reboot or an OBS process exit, Windows needs a startup mechanism to launch OBS again, for example Task Scheduler with --startstreaming.
Why does OBS say it is streaming when viewers cannot see the broadcast?
OBS’s encoder connection and YouTube’s viewer-facing broadcast state are related but distinct. Check that Live Control Room has the intended scheduled event selected and that its current auto-start and auto-stop settings match your plan. Verify the public watch page where applicable.
What should I put in Task Scheduler’s “Start in” field?
Use the folder containing the obs64.exe executable, not the full executable path. OBS documents this working-directory requirement for scheduled or otherwise automated Windows launches. Also check that the action’s program path and arguments are correct.
Should I add a delay before OBS starts?
Only if testing shows that your VPS starts OBS before its network route or DNS is ready. A delay or retry can help with a host-specific startup sequence, but it adds another behaviour to check and is not required on every VPS. Test it after observing a failure rather than adding it by default.