A reboot will stop the encoder process running on your Contabo VPS, so the YouTube broadcast can be interrupted. You can prepare the operating system and encoder to recover after startup, but you cannot make the reboot itself interruption-free or assume viewers will see continuous playback.
The practical goal is a tested recovery path: the VPS comes back, the encoder starts and can reach its media and YouTube, and you confirm that YouTube is receiving a healthy stream. The exact steps depend on your operating system and encoder, so verify their startup and retry behaviour rather than relying on an untested recipe.
Why a VPS reboot interrupts a live stream
A VPS reboot stops the guest operating system and the processes running inside it. That includes an encoder such as FFmpeg or OBS, its connection to YouTube, and any scripts responsible for choosing or looping media. When the operating system starts again, those processes do not necessarily return unless you have configured them to do so.
Even when the encoder starts at boot, the broadcast may not resume successfully. The media file might not be mounted yet, credentials or configuration may be missing, or the encoder may not retry a failed connection. YouTube may also need to receive a valid signal again before its live preview and stream status reflect the recovered broadcast.
Think of recovery as several separate steps rather than one switch: the VPS boots; the network and required storage are ready; the encoder process starts; it can read and encode the source; it connects to the intended YouTube ingestion address; and YouTube reports the incoming stream as expected. A failure at any one step can leave the machine running while the channel is still offline.
That distinction matters if your channel runs unattended overnight. A VPS status of “running” is not proof that the stream is live, and a process shown as active is not proof that YouTube is receiving usable video. The approach in how to make a 24/7 YouTube stream restart automatically after disconnecting covers the broader recovery problem; here, the focus is what changes specifically around a Contabo VPS reboot.
Set your expectation accordingly. A boot-time start and process recovery can reduce the amount of manual work after an interruption, but neither ensures an exact recovery time, automatic reconnect in every encoder, nor uninterrupted playback for viewers. You need to test the complete path with your own operating system, encoder, and YouTube setup.
Contabo Control Panel reboot vs operating-system reboot
There are two different places to initiate a restart. If your operating system is responsive and you can access it, Contabo advises considering a reboot from within the operating system. Its support guidance warns that suddenly shutting down the server can cause problems and should be a last resort. Read Contabo’s reboot guidance before choosing a method for your VPS.
A reboot requested inside the guest OS lets that system carry out its own shutdown and startup sequence. That is generally the more orderly choice when you can still administer the machine. It does not keep the encoder or stream running through the reboot: the operating system is still restarting, and the encoder still needs to launch and reconnect afterwards.
The Control Panel provides provider-level controls, including restarting a VPS. Use those controls when the operating system is unavailable or when you need to act outside it. The panel action is not a substitute for configuring boot-time startup inside the guest. If the panel stops or restarts the server, your setup still needs to handle the next operating-system boot and the encoder recovery that follows it.
| Action | When it is useful | What it does not establish |
|---|---|---|
| Reboot from the operating system | The guest is accessible and you can request an orderly restart | That the encoder will launch or that viewers will see no interruption |
| Restart from the Contabo Control Panel | The guest is inaccessible or you need a provider-level control | That the guest’s startup configuration is correct |
| Start the encoder manually after startup | Recovery is being diagnosed or an automatic start is not configured | That the next reboot will recover without manual work |
Contabo also documents VPS features such as snapshots and a rescue system. These can be useful for recovery work, but they do not keep an active broadcast going during a restart. A rescue environment is for accessing or repairing a server, not for running your normal encoder as if nothing happened. See the Contabo VPS documentation and its rescue-system instructions for the options available to your account.
For a planned restart, first make sure you can regain access and know how to check the encoder and stream afterwards. If the VPS is already unresponsive, a panel restart may be necessary, but treat it as an intervention that can interrupt the broadcast, not as a graceful way to preserve it.
Prepare the encoder to start at boot
An encoder started in a terminal or a desktop session may stop when that session ends or the machine reboots. To recover without signing in and launching it by hand, configure the encoder to start as part of the operating system’s boot process. How you do that depends on the Linux distribution, its service manager, and the encoder. Because the system details are not specified here, do not copy a service definition intended for a different machine and assume it will work.
Before configuring startup, document how the current stream is launched. Record the encoder application and version, the command or saved profile, the source video or playlist location, output settings, and the YouTube stream key’s secure storage location. Keep the stream key out of public scripts, screenshots, and support messages; treat it as a credential that allows a connection to your broadcast.
Then check the dependencies that must be ready when the startup task runs. If the media is on a mounted volume, confirm that it is available before the encoder tries to read it. If a playlist script generates a file list, confirm that the script and its working directory are accessible. If you use an overlay, audio track, or separate configuration file, include those dependencies in the test. A process that starts too early can fail even though it works when launched interactively later.
The boot configuration should also make failures visible. Keep a log that can show whether startup was attempted, whether the encoder opened its input, and whether it established an output connection. Make sure the log location is writable and has enough space for ordinary operation. Avoid logging secrets such as the full stream key.
Do not confuse “enabled at boot” with “confirmed working”. After configuring it, test a normal guest-OS reboot during a maintenance window. Once the machine is available, check that the expected process exists and that its logs show the intended input and output. The best FFmpeg output settings for your stream are a separate concern; the constant-frame-rate settings guide can help you review the video side without treating encoding settings as a reboot-recovery mechanism.
If your setup uses a graphical encoder, make sure it does not depend on a user logging into a desktop session unless that is an intentional part of the design. If it does, document who will log in and how the session is restored. For a headless VPS, a boot-managed process is often a better fit, but the correct configuration must match the software and operating system you actually run.
Configure process recovery after failure
Starting the encoder at boot handles one event: operating-system startup. It does not necessarily restart the encoder if it exits later because of an input error, an encoder fault, or a dropped connection. Process supervision can be configured to relaunch a failed process, but its behaviour depends on the chosen supervisor and how the encoder exits.
Decide what should count as a recoverable failure. An encoder that exits with an error is different from a process that remains alive but is stuck, and both differ from an encoder that is running while YouTube is not receiving usable video. A supervisor can generally respond to process exit; it cannot, by itself, prove that the live broadcast is healthy.
Configure and test the process manager according to its official documentation for your distribution and encoder. In particular, understand whether it restarts only after an unexpected exit, what happens after repeated failures, and whether a deliberate stop will be treated as a failure. Do not add aggressive retry loops without understanding their effect: repeated launches can obscure a missing file, invalid configuration, or bad credential instead of fixing it.
A recovery plan needs an observable signal. Check the supervisor’s status and logs, then inspect the encoder’s own output. Does the process report that it opened the expected media? Does it show an output connection attempt? Do errors point to a missing file, permissions, network reachability, or an invalid stream key? Keep a short, private runbook with the steps to inspect these points, and update it when you change the encoder command or media layout.
For a looped channel, include the playlist or rotation layer in your checks. Restarting the encoder may only send the first file, not resume the scheduled block your viewers expect. The article on fixing a playlist rotation script that skips a scheduled block is relevant when the encoder is active but the schedule itself has not recovered.
Finally, consider what must happen if recovery fails. Decide who receives an alert, how they can access the VPS, and what they should inspect before starting a second encoder process. Two encoders publishing with the same key or competing for the same output can create confusion. Recovery is safer when the runbook distinguishes checking an existing process from launching a new one.
Check VPS availability and encoder status
After a restart, work from the machine outward. First confirm in the Contabo Control Panel that the VPS is running. Then try the access method you normally use, such as SSH. A panel indicator and a successful login answer different questions: the first says the VPS is powered on, while the second shows that the guest OS and network path are responding to you.
Once logged in, check the expected encoder service or process and inspect its recent logs. Confirm that it has the right input file, playlist, or capture source and that the file can be read. Verify that the process is using the intended configuration and that the stream key is available to it without exposing the key in a terminal recording or shared log.
If the encoder is absent, find out whether the boot task was enabled and whether it failed. If it is present but not producing output, inspect its errors before restarting it again. A missing mount, permission change, expired or replaced key, or a network problem calls for a different fix than a service that was simply not enabled at boot.
The network check should be specific enough to isolate the problem. Confirm that the VPS can reach the required YouTube ingestion destination using the methods supported by your operating system and encoder. Do not infer that a generic internet connection test proves the streaming path works. If you use a playlist, confirm that the playlist and its media references are valid from the encoder’s runtime context, not only from your own login session.
Keep checks proportionate. The aim is not to inspect every system component after every restart, but to have a short sequence that gives you evidence at each stage: VPS accessible, encoder active, source available, output attempted. If you need to restore server access rather than a broadcast, Contabo’s rescue system may help with repair, but it is a separate recovery task and will not verify YouTube ingestion.
Verify stream health in YouTube Live Control Room
A running VPS and encoder are only part of the check. Open YouTube Live Control Room for the intended broadcast and confirm that the correct stream is receiving video and that its health information is acceptable. Check the preview and any warnings rather than relying on the title or stream page alone. This is where you can distinguish an encoder that appears active locally from a feed YouTube is actually ingesting.
YouTube’s developer documentation describes stream status and health fields, along with primary and optional backup ingestion addresses. Those fields can help diagnose whether YouTube is receiving a stream; they do not show that your encoder automatically reconnects after a reboot. See the YouTube LiveStreams reference for the documented fields and stream health messages for the meaning of reported conditions.
One documented condition is videoIngestionStarved: YouTube says it is not receiving enough video to maintain smooth streaming, so viewers will experience buffering. That message is a reason to investigate incoming video and encoder output, not proof that the VPS needs another reboot. Check the encoder’s logs and output settings, then see whether the health report changes after a deliberate correction.
If your encoder is configured to use a backup ingestion address, confirm that configuration before expecting it to help. YouTube’s documentation describes available addresses, but their presence in the API does not guarantee that a particular encoder will switch to one automatically. If you use a backup route, test it under controlled conditions and document how you know it was selected.
Also confirm that you are looking at the right event or stream in Studio. A valid stream key can still be associated with a different broadcast configuration than the one you intend to run. If YouTube does not show the expected incoming video, verify the selected stream, key, endpoint, and encoder output together. The Nginx RTMP troubleshooting guide discusses a related case where local streaming components and Studio visibility need to be checked separately.
Stream health is a diagnostic view, not a promise about every viewer’s experience. After recovery, observe the preview and status long enough to see whether the reported condition is stable, and if possible check the public viewing experience from another connection. Do not announce that a reboot was interruption-free simply because the stream eventually returned.
Plan and test a controlled restart
Do not make the first test of your boot configuration during an important devotional programme, news loop, or business broadcast. Choose a maintenance window, tell anyone who relies on the channel that a short interruption is possible, and keep a way to reach the VPS if automatic startup fails. Note the current encoder state and the YouTube stream you intend to verify.
Use a guest operating-system reboot when the OS is accessible, following Contabo’s guidance. When it is back, follow the same recovery checklist you will use during an actual incident: confirm VPS access, inspect startup and encoder logs, check the source, and verify stream status and health in YouTube. Record what worked and what required manual intervention. If the OS cannot be reached and you need a Control Panel restart, treat that as a separate test of the provider-level recovery path.
A useful test should answer questions, not merely end with a green indicator. Did the encoder start without a logged-in user? Was the media ready when it started? Did the process remain active? Did it reconnect, or did someone have to intervene? Did YouTube show the intended incoming stream? Were there health warnings? Write down any gap and retest after fixing it.
Repeat the test after meaningful changes to the operating system, encoder version, startup configuration, storage mount, playlist, or stream key. A setup that recovered last month may not behave the same after a configuration change. Keep the runbook simple enough that someone else can follow it, including the distinction between a normal OS reboot and a Control Panel action.
If maintaining a VPS and checking recovery at the system level is not work you want to own, using a managed way to turn an uploaded video into a YouTube live stream may remove the need to keep your own computer running and monitor an encoder process. StreamNeo is relevant to that specific operational burden, but it is YouTube-only and does not remove the need to confirm that your channel and content are ready.
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
How do I keep my YouTube stream running after a VPS reboot?
You cannot keep the stream itself running while the VPS and its processes restart. Configure the encoder to start with the operating system, ensure its media and credentials are available, and check YouTube Live Control Room after startup. Test the full sequence before depending on it.
How can I make my stream restart automatically after my Contabo VPS reboots?
Configure a boot-time task or service for your encoder using the instructions for your operating system and encoder, then configure appropriate process recovery for failures. The exact setup varies, and boot startup alone does not confirm a successful connection to YouTube. Check the process logs and the stream’s health after a planned test reboot.
Should I reboot from Contabo’s panel or from the operating system?
When the operating system is reachable, Contabo advises considering an in-OS reboot; its guidance says sudden shutdown should be a last resort. Use the Control Panel when the guest is unavailable or you need provider-level control. Either route interrupts running processes, so verify encoder recovery and YouTube ingestion afterwards.
Does YouTube’s backup ingestion address guarantee reconnection?
No. YouTube documents primary and optional backup ingestion addresses, but that does not establish that your encoder will switch endpoints or reconnect automatically. Check your encoder’s configuration and documentation, then test the behaviour with your own stream.