To restart a YouTube stream automatically on an OVHcloud VPS, supervise the encoder process with a Linux service manager such as systemd. That brings the sender process back after a failure it detects, but it does not guarantee YouTube has resumed or restarted the live event; check the ingest feed and broadcast state separately.
If you are asking, “How do I make FFmpeg restart if it crashes?”, the practical answer is to configure a service with a restart policy, then test both sides of the connection: the VPS process and YouTube Live Control Room. A system service handles process recovery; YouTube’s auto-start settings and broadcast lifecycle determine what viewers see.
What automatic restart can and cannot do
Your VPS runs the encoder. FFmpeg, for example, reads a video or playlist, encodes it and sends the resulting feed to YouTube using a stream URL and key. A service manager can watch the encoder process and start it again if it exits unexpectedly. This is useful when a process crashes overnight and nobody is at a terminal to relaunch it.
There are limits. A restart policy cannot repair a bad command, restore a deleted file, renew an invalid key, fix a firewall rule or make YouTube accept a feed. It also cannot tell you, by itself, whether the broadcast event has returned to a live state. The encoder may be running while sending no usable video, or YouTube may be receiving video while a scheduled broadcast still awaits a manual Go live action.
Treat recovery as two separate questions:
- Is the local sender healthy? Check that systemd considers the service active and that the latest logs show FFmpeg started and is making progress.
- Is the intended YouTube event receiving the feed and live? Check Live Control Room or, for an API-managed workflow, the stream and broadcast states.
YouTube models broadcasts and streams as distinct resources. A broadcast is the event; a stream is the incoming feed to which the event is bound. The YouTube Live Streaming API resource guide describes that distinction and the binding between them. Pointing a recovered encoder at the wrong stream can therefore leave the intended event without a feed.
If your channel carries a recurring loop rather than one-off scheduled events, first decide how its content should repeat and how you will operate it when the VPS needs maintenance. The practical choices in a guide to looping a Hindi devotional playlist on YouTube Live are useful context, though the process supervision steps below apply to other continuous formats too.
Supervise the encoder on the VPS
On an OVHcloud VPS, you administer the operating system and the services running on it. OVHcloud describes its VPS as a virtual machine with full root access and places system administration, security and stability responsibilities with the customer in its VPS documentation. That gives you room to install and manage an encoder, but also means you need to understand the service configuration you put in place.
For a long-running FFmpeg command, a systemd service is usually easier to monitor and recover than a shell session left running in a terminal. A shell can end when you disconnect, and a terminal multiplexer does not automatically decide that an exited process should be restarted. A service unit records the command, runs it under a chosen account and applies a restart policy.
Before writing the unit, make sure the basic command works on its own. Run it in a controlled test, verify that it opens the intended source and reaches the correct YouTube ingest endpoint, then stop it cleanly. Record the executable path, input path, working directory, user and any environment variables it needs. A command that only works from your interactive shell may fail as a service because the service has a different environment and permissions.
Here is an implementation pattern, not an OVHcloud-prescribed unit. Adapt it to your Linux distribution, FFmpeg path, account, environment file and complete encoder command:
[Unit]
Description=YouTube encoder
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=streamer
WorkingDirectory=/srv/youtube
EnvironmentFile=/etc/youtube-stream.env
ExecStart=/usr/bin/ffmpeg -re -stream_loop -1 -i /srv/youtube/loop.mp4 -c:v libx264 -c:a aac -f flv "$YOUTUBE_URL/$YOUTUBE_KEY"
Restart=on-failure
RestartSec=10
[Install]
WantedBy=multi-user.target
This example assumes a local file and a particular FFmpeg build. Your source, codecs, output format and network requirements may differ. If your command uses shell expansions or shell-only syntax, do not assume systemd will interpret them as an interactive shell would; make those choices explicit and test the unit as a service. The Restart and delay lines are an example policy: verify their behaviour against the systemd version and distribution on your VPS rather than treating the snippet as a universal configuration.
Save a unit file under the appropriate system service directory for your distribution, then have systemd reload its unit definitions before enabling or starting the service. Common operations include systemctl daemon-reload, systemctl enable --now youtube-encoder.service, and systemctl status youtube-encoder.service. Check your distribution’s documentation if file locations or commands differ. If you use a different service manager, use its equivalent supervision and logging facilities.
A restart delay matters because repeated immediate failures can create a rapid loop of starts and exits. The delay does not resolve the cause; it gives you a controlled retry interval and makes logs easier to inspect. Add service limits or escalation procedures only after deciding how you will detect a persistent failure and who will investigate it.
Configure the YouTube URL and key securely
In YouTube Studio, create or choose the intended encoder stream and use the stream URL and stream key shown for it. YouTube Help explains that the key identifies where the encoder sends the feed and allows YouTube to accept it in its encoder streaming settings. The key is credential-like: anyone who obtains it may be able to send video to that stream.
Avoid putting the key directly into a unit file that may be copied into tickets, backups or public configuration repositories. In the example, an environment file keeps the URL and key separate from the service definition. Restrict that file so only the service account and administrators who need it can read it. Do not print its contents in routine diagnostic output, and do not paste the key into screenshots or support messages. If you suspect it has been exposed, reset it in YouTube Studio and update the service configuration before starting the encoder again.
Check that the service points to the intended stream key, not a test stream or a different channel’s key. This sounds obvious, but a VPS can retain an old environment file after a stream is replaced or moved. For a private test, keep the destination and event clearly labelled, then verify the preview in Live Control Room before using a public event.
The distinction between an encoder choice and a channel configuration is useful here. If you are still deciding whether FFmpeg suits your loop, the comparison of OBS and FFmpeg for a nonstop sleep ambience stream explains the operating trade-offs. Whichever encoder you use, the service needs a reliable command and the correct destination credentials.
Set restart behaviour for process failure
A service manager can restart a process only when it recognises that the process has stopped or failed. Restart=on-failure is commonly used for a long-running sender: it asks systemd to restart the service after a non-zero exit, a signal or a timeout, subject to systemd’s service rules. Confirm the exact behaviour for your systemd version and unit type in the systemd service documentation.
Choose the policy to match your command’s expected lifecycle. A scheduled encoder that should exit normally at the end of an event should not necessarily be restarted after every normal exit. A continuous loop is different: an exit probably deserves attention and a restart attempt. Restart=always may be appropriate in some persistent workflows, but it can also relaunch a process that you intentionally stopped. Test what happens when you stop the unit manually and when FFmpeg exits with an error; do not infer the outcome from the setting’s name alone.
The RestartSec delay in the example spaces out attempts. Do not treat it as a guarantee that recovery will finish within that interval. It is only a pause before another local start attempt. The new process still has to open its files, reach the network, authenticate to the ingest endpoint and deliver video YouTube can use.
Also consider what counts as a failure in your setup. FFmpeg can remain alive while stuck on an input or repeatedly report errors. A service manager that only watches process exit will not necessarily identify every unhealthy output condition. Read the encoder logs and consider whether a separate health check is needed for your source and workflow. Do not add an automatic kill-and-restart check until you have tested it against normal buffering, temporary network disruption and the encoder’s expected behaviour.
For a persistent channel, the goal is usually to restore a continuing feed, while a scheduled event may need explicit start and end control. YouTube’s API describes enableAutoStart as starting a broadcast when video arrives on its bound stream, and enableAutoStop as stopping it after the owner stops sending video. Those are YouTube broadcast settings, not systemd settings. Keep them aligned with the kind of event you run rather than copying a policy from another channel.
Check service status and recovery logs
After enabling the unit, confirm it starts and stays in the expected state. Use systemctl status youtube-encoder.service for a concise view of whether systemd considers the unit active and to see recent log lines. For a fuller view, inspect the service journal with a command such as journalctl -u youtube-encoder.service; add a time range or follow mode when you are investigating a particular recovery.
A healthy-looking service status is one piece of evidence, not a success certificate. Look for the sequence around a failure: the original FFmpeg exit, systemd’s decision to restart, a new process start, and encoder output that indicates the intended input and output are active. If the service starts and immediately stops, check for a missing binary, inaccessible media file, malformed command, permission problem or absent environment file. If it runs but reports connection errors, investigate the stream URL, key, firewall and route to YouTube.
Make a deliberate test before relying on the configuration overnight. In a private or otherwise controlled test, stop the encoder process in a way that exercises the failure policy, then confirm systemd attempts a restart and that the new process can send a feed. A manual systemctl stop is an intentional service stop and may not behave like an unexpected process failure, so use a test that matches the policy you configured and verify the resulting logs. Avoid testing against a public event unless you understand how its current auto-start and auto-stop settings will react.
Keep enough log history to diagnose a problem without allowing logs to grow without bounds. Review your system’s journal retention settings and the storage available on the VPS. If the service runs under an unprivileged account, ensure it can read the media and configuration files it requires but cannot change unrelated system files. These checks matter because the VPS administrator, not the host’s support team, is responsible for the guest operating system and its services.
Verify the feed and event in Live Control Room
Once the service restarts, open the intended stream or scheduled broadcast in YouTube Live Control Room. Check the preview and status indicators for incoming video, and confirm that the picture and sound are the expected ones. Do not rely on the word “active” in systemd to tell you that YouTube has received anything; it describes the local service process.
YouTube’s encoder workflow asks you to start the encoder, wait for a preview, and, for a scheduled stream where required, select Go live. Its encoder help guidance is a reminder to check the actual event controls rather than assuming a restarted sender makes every broadcast live automatically. If auto-start is enabled for the bound stream, incoming video can start the broadcast; if it is disabled, an operator action or API transition may still be needed.
For API-managed workflows, check both resources. Google’s lifecycle guidance describes liveStream.status.streamStatus as active when YouTube servers are receiving encoder data. Then inspect the broadcast lifecycle state as well: receiving a feed and being live to viewers are distinct conditions. The documented API transition procedure commonly waits 5 to 10 seconds after a transition, with some transitions taking up to a minute. Those are guidance timings for the API workflow, not a promised reconnect time for your encoder or a guarantee of continuous playback.
A broadcast is bound to one stream, while a stream can be reused for broadcasts. Make sure the recovered FFmpeg process is feeding the stream bound to the event you intend to show. If you are building a schedule of separate programmes rather than a single recurring channel, the guide to playlist scheduling tools for multiple YouTube channels in India can help frame the distinction between content scheduling and the transport process that sends a feed.
After a real interruption, inspect the viewer-facing event as well as the control room. The event may have stopped, remained waiting, or resumed according to its settings and current YouTube state. Check that the video is actually playing on the intended event before assuming viewers have returned to it. If you use an API to create, bind or transition broadcasts, log the resource IDs and responses so that you can distinguish an encoder recovery from a broadcast transition.
Plan for failures the service manager cannot fix
A restart loop can keep trying the same broken command. It cannot make the input file readable, supply a missing environment variable, correct a stream key, repair an application bug or resolve a VPS network outage. Set an alert or a regular check for repeated restarts and prolonged absence of a YouTube preview, because the system service and YouTube feed can fail independently.
If the VPS loses network connectivity, a service restart may succeed locally and still fail to connect upstream. Check local firewall rules, DNS resolution and general connectivity before changing the encoder command. OVHcloud’s rescue mode can help diagnose network problems, repair a broken operating system or fix a misconfigured software firewall, but booting into that environment requires a reboot and interrupts services. Follow the current OVHcloud rescue mode documentation and plan a maintenance window if the channel is already live.
For a content error, inspect the source file and playlist independently. A sender can remain healthy while it streams the wrong frame, silence or an expired playlist item. If your loop uses a playlist file with non-ASCII filenames, the troubleshooting guide for FFmpeg playlists saved in Devanagari encoding covers one specific failure mode worth ruling out for Hindi-language content.
Finally, decide how you will handle an event that needs a human action. Someone may need to press Go live, select a different event, rotate a compromised key or notify viewers that playback was interrupted. Keep the service restart policy narrowly focused on bringing back the sender, and keep a separate runbook for YouTube event controls, credentials, content checks and escalation. That separation makes it clearer which part of the system recovered and which still needs attention.
If you want to avoid maintaining a VPS service and its process recovery checks, StreamNeo can remove that specific operating burden for a prerecorded file by turning it into a YouTube live stream without keeping your computer on; you still need to verify your channel and event settings.
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 restarting FFmpeg bring the same YouTube live event back?
Not necessarily. The encoder process and YouTube broadcast have separate state, and the outcome depends on the stream-to-broadcast binding and the event’s auto-start settings or API state. Check Live Control Room to confirm what viewers can see.
How do I make FFmpeg restart if it crashes?
Run it as a supervised service, such as a systemd unit with a restart policy that suits its expected lifecycle. Test the policy and review the journal so you know whether the failure was detected and whether the replacement process started successfully.
How can I tell whether YouTube is receiving the recovered feed?
Check the intended stream in Live Control Room and look for its preview and incoming-feed status. For an API-managed stream, Google’s lifecycle guide identifies streamStatus=active as YouTube receiving encoder data; also check the separate broadcast state.
Should I use auto-start for a scheduled event?
It depends on how you operate the event. Auto-start can start a broadcast when video reaches its bound stream, while a workflow with auto-start disabled may require an operator action or API transition. Confirm the setting on the actual stream and event rather than assuming a VPS restart changes it.