If FFmpeg stops on a Hetzner-hosted Linux server, a service manager such as systemd can start it again after the process exits. That is different from FFmpeg recovering a dropped input or temporary output connection while it is still running.
The reliable approach is to identify the failure first, inspect the actual exit evidence, then supervise the same FFmpeg command you use in production. A restart policy can relaunch a process, but it cannot correct an invalid stream key, unavailable media, unsuitable settings or a YouTube event that has ended.
First identify which part failed
“FFmpeg stopped” can describe several different situations. The process may have exited completely, it may still be running while an input connection is failing, or it may still be alive while its connection to YouTube is temporarily unavailable. These cases need different recovery methods.
Start by checking whether an FFmpeg process still exists. A process that has exited needs operating-system supervision. A process that remains alive needs investigation of its input, output, protocol and logs before you add more restarts.
| What you observe | What it usually means to examine | Suitable recovery layer |
|---|---|---|
| No FFmpeg process remains | The process exited or was terminated | systemd or another process supervisor |
| FFmpeg remains running and an input drops | Input protocol or source interruption | Applicable FFmpeg reconnect options |
| FFmpeg remains running but output is failing | Network or output muxer behaviour | Output recovery options and YouTube status |
| FFmpeg reconnects but the event does not resume as expected | YouTube event configuration or stream lifecycle | Live Control Room settings and preview |
The distinction matters because FFmpeg’s reconnect option is documented for supported protocol situations, including reconnecting after a connection is lost before end of file. It is not a general command to launch a new FFmpeg process after the old one has exited. Read the FFmpeg protocol documentation for the options supported by your input and installed build.
Similarly, the FIFO muxer has output recovery features for some transient failures. Those features operate inside FFmpeg. They do not replace a service manager when the main process has crashed, been killed, or stopped because of an unrecoverable configuration error.
If your source is a local looped video, an input reconnect option may not address the real problem at all. If the file cannot be opened, the codec is unsupported, storage has filled, or the command exits immediately, systemd will only repeat the same failure. That is why the first question is not “which restart flag should I use”, but “is the process still there, and what caused its state to change”.
Read the logs and exit status
Before changing the service, capture evidence from the failure. Look at the systemd journal if FFmpeg is already running as a service, and look at FFmpeg’s own standard error output if it is launched from a wrapper or terminal. The final lines often distinguish an authentication problem from an input problem, a deliberate termination, a resource issue or a malformed command.
Useful evidence includes:
- the exact command or wrapper script that was executed
- the FFmpeg version and build information
- the input URL or file type, without exposing private credentials
- the final FFmpeg log lines before exit
- the process exit status
- the time of the failure
- whether YouTube showed a preview, a disconnected encoder or an ended event
Do not rely on a dashboard label alone. “Offline” in YouTube Studio does not tell you whether FFmpeg exited, lost its network route, sent invalid media or was still sending to an event that was no longer available.
If the service manager reports that the process exited with a non-zero status, record that status and the surrounding log lines. A clean exit can also be significant. For example, a wrapper may deliberately stop FFmpeg when a file ends, or a script may interpret an empty input as a completed job. A restart policy configured only for failures may not relaunch a process that exits successfully.
Run the exact production command manually in a safe test window if you need to reproduce the fault. Use a separate YouTube event or an unlisted test where appropriate. Do not paste the stream key into a shared ticket, shell history, screenshot or public log. If the command is stored in a script, inspect the script and its permissions rather than copying secrets into a chat message.
Keep the installed build in mind. Online FFmpeg documentation describes the current project documentation, while a package installed on your server may expose different options. Check the local build’s help output and test the flags against the same binary that the service will execute. A command that works with one FFmpeg package is not automatically portable to another.
For a longer-running channel, the bitrate and format checklist can help separate media compatibility problems from process supervision. It will not diagnose a crashed process, but it gives you a more stable baseline before you begin failure testing.
Use systemd to supervise the foreground process
A supervisor works best when FFmpeg runs as a foreground process. In that arrangement, systemd starts FFmpeg, observes its process state and receives the exit result directly. Avoid wrapping the command in a script that backgrounds FFmpeg and then exits, because systemd may believe the service finished while the real encoder is running elsewhere.
The service definition should identify the account that runs the stream, the working directory if one is needed, the executable or wrapper, and the restart behaviour. Keep the FFmpeg invocation in one controlled place so that the command used after a failure is the same command you tested manually.
A wrapper script can be useful when the command is long or needs a small amount of preparation. It should use an absolute path to FFmpeg, return FFmpeg’s exit status, and avoid hiding failures. If the wrapper catches an error and exits successfully, the supervisor may make the wrong decision about whether to restart.
Systemd is general Linux process supervision guidance here, not a Hetzner-specific recipe. The appropriate unit syntax, package paths, permissions and service layout depend on the operating system image and the systemd version installed on your server. Confirm those details on the machine rather than assuming that a unit written for another distribution will behave identically.
After changing a unit, validate the configuration and inspect the service status before treating it as ready. Make sure the service account can read the media file, reach the required network destination, access any certificate or configuration files, and write only to the locations it needs. A unit that starts successfully but cannot read its input is not a recovered stream.
The service should also have a clear stop and start procedure. You need to know how to stop it without leaving another manually started FFmpeg process behind, and how to identify duplicate processes before testing. Two encoders using the same YouTube stream key can create confusing results that look like intermittent network failure.
This separation between the application and the supervisor is useful for any unattended channel. The discussion of preventing OBS from stopping after an update covers a different encoder, but the underlying lesson is similar: establish what owns the running process, then test what happens when that process disappears.
Choose an on-failure policy carefully
An on-failure policy tells systemd to attempt a new start when the service meets the policy’s failure conditions. It does not mean that the next start will produce a healthy YouTube broadcast. The new process may fail in the same way, or YouTube may reject the connection for a separate reason.
Choose the policy around the failure you actually want to recover from. If the process should not be relaunched after a deliberate clean stop, an on-failure approach may be more suitable than an unconditional restart. If a wrapper turns every problem into a successful exit, fix the wrapper or choose a policy that matches its real exit behaviour rather than hiding the distinction.
Add a delay between attempts and use a start-rate limit. Without those safeguards, a bad input path, invalid option or exhausted resource can create a tight crash loop. Repeated starts make logs harder to read and can add load without improving the broadcast. A delay also gives you time to notice the first failure instead of receiving a long sequence of identical restarts.
The exact systemd directives and acceptable values depend on the operating system and package version. Use the systemd documentation and the help available on the server to confirm the syntax. Do not copy a Hetzner-specific unit from an unverified post and assume it is authoritative for your image.
A restart policy should be paired with visibility. Record when the service starts, when it exits, how often it has restarted and whether the new process reaches the expected output state. If the same service restarts repeatedly, treat that as a fault requiring diagnosis, not as proof that automation is working.
Common causes of repeated failure include:
- a missing or unreadable local file
- an input URL that has expired or is unavailable
- an FFmpeg option unsupported by the installed build
- an incorrect YouTube stream URL or key
- incompatible audio or video settings
- insufficient disk space or memory
- an event that has ended or is not configured to accept the encoder
- a wrapper script that returns the wrong exit status
You can use the daily YouTube live scheduling guide to review event scheduling separately. Scheduling controls when an event is expected to occur; systemd controls what happens to the encoder process. Neither one substitutes for the other.
Test with the production input and settings
Do not test only by starting and stopping an empty FFmpeg command. Recovery must be tested with the actual FFmpeg build, the real input type, the intended output settings and the YouTube event configuration you will use overnight.
First establish a normal baseline. Confirm that the input plays continuously, that FFmpeg reports the expected audio and video streams, and that the YouTube preview receives both. Check the broadcast from a separate device or connection where practical. Also inspect the local archive or recording if YouTube creates one, because a preview can look normal while the recorded output exposes missing audio, frozen video or an incorrect frame rate.
Then perform a controlled process failure. Stop the service using the planned operational method and separately test an unexpected termination in a non-critical event. Observe whether the process actually exits, whether systemd records the failure, whether a new process starts after the configured delay and whether the new process uses the intended command and permissions.
Watch YouTube Live Control Room during the test. Confirm whether the encoder reconnects to the same event, whether the preview returns and whether playback resumes as expected. YouTube recommends testing failover and checking the preview, accessibility, local archive and stream audio and video in its live streaming tips. Treat that as a test plan, not as a guarantee that every restart will be accepted.
If a transient input or network interruption matters to your channel, test that separately. A process that remains alive during an interruption is not the same case as a process that exits. For supported inputs, inspect the reconnect options in the installed FFmpeg build. For output recovery, review the FIFO muxer documentation and validate the relevant behaviour with your actual protocol and command. The FFmpeg muxer documentation describes recovery options, but your build and use case still require testing.
Do not run the first destructive test during an important devotional programme, local news loop or paid event. Use a separate event or an unlisted test where that matches your channel’s needs. A process restart can interact with YouTube’s event lifecycle, and repeatedly stopping a real broadcast can end it rather than merely reconnecting the encoder.
Protect the stream key and verify YouTube’s status
YouTube expects the encoder to send to the stream URL with the stream key. The official encoder instructions explain where to retrieve those details and how the encoder connection relates to going live. Use the current values from Live Control Room rather than relying on an old screenshot or a key copied into several scripts.
Prefer RTMPS where it is available and supported by your setup. YouTube describes RTMPS as RTMP carried over TLS or SSL and instructs creators to retrieve the RTMPS URL from Live Control Room. Keep the stream key private, because anyone who obtains it may be able to send content to the event.
Avoid putting the key in a world-readable unit file, a shared wrapper, a public repository or routine diagnostic output. Restrict file permissions and access to the account that needs the credential, or use the secret-handling method supported by your operating system and deployment. Check logs after a failed start to ensure the key has not been printed as part of a command line or error message.
Review auto-start and auto-stop for the specific event. YouTube’s stream settings guidance explains that these settings affect whether the encoder can start or stop the stream. Reused stream settings can carry assumptions from an earlier event, so check them instead of assuming that a restarted FFmpeg process will have the lifecycle you want.
A reconnecting encoder may not produce the result you expect if the event has ended, the key has been changed, the stream is scheduled differently or auto-start is disabled. Conversely, a service may be restarting correctly while YouTube is correctly showing no live event because the encoder is not sending valid media. Check both sides of the connection.
For an unattended channel, protect more than the key. Keep the server account, service files, media files and logs accessible only to the people who operate the channel. If you hand administration to someone else, rotate the stream key afterwards if it may have been exposed. YouTube’s current help pages should be your reference for the available security and live-stream controls.
Build a recovery routine you can observe
Automatic restarts are useful only when someone can tell the difference between recovery and repetition. Define what a healthy service looks like: the FFmpeg process is present, the input is advancing, the output connection is accepted and YouTube shows the expected preview or live playback.
Keep a simple record of failed starts and the reason found in the logs. A pattern such as “starts, exits immediately, repeats” points towards the command, input or permissions. A pattern such as “runs for a while, loses the input, remains active” points towards input handling. A pattern such as “runs locally but does not appear in Live Control Room” points towards the stream URL, key, event state or output compatibility.
Review disk space, memory and file availability as part of routine maintenance. These are not fixed Hetzner or YouTube limits, and they vary with the server plan, media and command. The important point is that a supervisor cannot create resources that the process needs. If the server cannot read the source or write required temporary data, another restart will produce the same result.
If you do not want to maintain a Linux process, secret files, logs and failure tests yourself, a hosted workflow can remove that particular server administration task. StreamNeo is designed for the narrower case where you upload the video once, provide the YouTube connection details and let the broadcast continue without your computer running, while still requiring you to manage the channel and YouTube settings correctly.
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
Will systemd restart FFmpeg if the internet briefly drops?
Only if the interruption causes the FFmpeg process to exit and the service policy treats that exit as a restart condition. If FFmpeg remains alive, its protocol or output handling determines what happens. Test the specific input, output and FFmpeg build instead of assuming that a process restart policy covers a network interruption.
Does restarting FFmpeg guarantee that YouTube goes live again?
No. The process may restart while the stream key, event settings, media output or YouTube event state still prevents a healthy broadcast. Check the Live Control Room preview, stream lifecycle settings and logs after a controlled restart.
Should I use a Hetzner-specific systemd configuration?
There is no single verified Hetzner-specific recipe that applies to every server image and FFmpeg installation. Use general systemd supervision principles, then verify paths, permissions, package versions and directives on your own server before relying on the service.
How can I avoid an endless restart loop?
Add a delay and a start-rate limit appropriate to your systemd version, then monitor repeated failures rather than treating them as successful recovery. Investigate the first repeated error, especially if the input is missing, the key is invalid or the command exits immediately.