A stream stopping after a few hours does not, by itself, show that Contabo caused the failure. First work out whether FFmpeg exited, its input ended, output delivery stalled, or the VPS or network was disrupted; each points to a different fix.
Before changing flags, save the command, FFmpeg version, full logs around the stop, and the VPS metrics for the same time. A restart can restore a stream after a process exit, but it cannot correct a dead source, invalid destination, or continuing network fault.
Preserve the command, version and full logs
Start by making a copy of the exact command that was running, including line breaks, environment variables, and any wrapper or service configuration that launches it. Redact stream keys and other credentials before sharing the command, but preserve where each input and output option appears. FFmpeg options are position-sensitive: an option placed before an input may apply to that input, while an output option belongs in the relevant output group. The FFmpeg command-line documentation explains option ordering and command structure.
Record the installed version with ffmpeg -version, along with the operating system and how the process is started: an interactive shell, a background job, or a service manager. Builds can differ in supported protocols and options, so a command copied from a different version may not behave as expected. Note whether the source is a local file, a network URL, or another live feed, and whether the destination is YouTube RTMP or another protocol.
Save the entire log, not just the final line. Capture several minutes before the failure if possible, then note the exact time and timezone at which the stream stopped or appeared to stop. Look for the last input read, output write, warning, error, and process exit status. If a service manager restarts FFmpeg, collect logs from both sides of that restart; otherwise the useful failure may be hidden by the new process's startup messages.
Also note what viewers or YouTube Studio showed. A frozen picture, an ended broadcast, and a dropped connection are different observations. If you are already tracking stream health, compare the incident with your YouTube live audio sync troubleshooting checklist; a stream can remain visible while an underlying media issue develops.
Check whether FFmpeg exited
At the time of failure, determine whether the FFmpeg process still exists. Use the process list or the status reported by your service manager, and record the exit code if available. If it exited, the final log lines and status are the starting evidence. Errors about opening an input, encoding, writing an output, or an invalid option suggest different next steps; do not treat every non-zero exit as a VPS failure.
If you launch FFmpeg manually over SSH, a disconnected terminal can complicate diagnosis or end a process depending on how it was started. For a long-running broadcast, run it under a service manager with logs and a deliberate restart policy rather than relying on a terminal session. FFmpeg's FAQ describes -nostdin for background operation, where interactive console input checks are not wanted. It is not a reconnection option and does not make the process resilient to a failed source or destination.
A restart policy is useful only for the failure it can address: a process that exited. It may bring the command back after a crash, but it will not fix a wrong stream key, a source that has ended, an unavailable destination, or a network path that remains down. It can also repeatedly launch a command that fails immediately. Set any restart behaviour with logs and a sensible delay, and confirm that a new process actually resumes useful input and output rather than merely appearing in the process list.
If FFmpeg is still running, do not restart it immediately. First check whether it is reading input and writing output. A live process may be blocked or stalled; process existence alone does not establish that the broadcast is progressing. Preserve its status and logs before intervening.
Check whether the input stopped or disconnected
Identify the input side of the command and inspect what FFmpeg reported just before the stop. For a file, check whether it reached the end or encountered a read error. For a network input, look for timeout, connection reset, end-of-file, or protocol-specific messages. If the input is meant to be continuous but its packets stop arriving, changing output settings will not restore the source.
Reconnect options are documented by FFmpeg for particular protocols and behaviours. These include reconnect, reconnect_at_eof, reconnect_on_network_error, reconnect_on_http_error, and related retry controls. Their availability and meaning depend on the protocol and installed build; consult the FFmpeg protocol documentation for the exact input rather than adding a bundle of flags from an example.
In particular, reconnect_at_eof treats end-of-file as an error and attempts recovery. That can make sense for an input expected to be endless, but can be wrong when a finite file is supposed to end the job. Decide first whether the desired behaviour is to stop at EOF, loop a file, or reconnect to a live source. For a local playlist, verify the media itself and its looping logic; this is a separate problem from network reconnection. The guide to finding silent files in a 24/7 music playlist is useful when playback continues but the content has gone quiet.
Do not assume an input reconnect flag repairs publishing. Input and output are separate directions. A source reconnect may restore packets arriving at FFmpeg, but it does not reopen a failed YouTube publishing connection unless the output mechanism also recovers.
Check whether output delivery failed
If FFmpeg remains alive and input packets continue, examine whether output writes continue. Logs may show a connection error, write failure, timeout, or repeated attempts to send data. A process that keeps running while its output is stalled is not the same case as a process exit, so a service restart rule may never trigger.
Confirm the destination URL and stream key without exposing either in a public log or support ticket. Check whether YouTube Studio still recognises the broadcast and whether the scheduled stream is the one associated with the key. A mismatch between the key and intended scheduled event can look like a publishing problem; see how to check a YouTube stream key's scheduled stream.
FFmpeg's FIFO muxer has recovery settings, including attempt_recovery and recovery_wait_time, for supported situations. These are not universal guarantees: verify that the command actually uses the relevant muxer, that the output format and protocol support the behaviour, and that the installed version recognises the options. An RTMP disconnect, invalid credentials, or an unavailable destination may not be recoverable by the same mechanism. Avoid transplanting a sample command until you know which output component failed.
When testing an output change, use a controlled test stream or a time when an interruption is acceptable. Keep the input unchanged if possible so you can compare logs before and after the change. If you change the source, output, service policy, and network configuration together, a successful run will not tell you which change mattered.
Review VPS and network conditions
Match server metrics to the incident timestamp. Check CPU and memory pressure, swap activity, disk space and I/O, and network traffic. A process can fail under resource pressure, while an overloaded or misconfigured network path can interrupt either incoming media or publishing. Record the values and any system messages around the same period rather than relying on a general impression that the VPS was busy.
Review firewall rules, interface configuration, routes, and any changes to them. Check whether other network services on the VPS were reachable when the stream stopped. If several services lost connectivity at once, that is different evidence from a single FFmpeg output error. Also compare the VPS's actual traffic and status with the provider account and server information.
Contabo Support's page on bandwidth and traffic limits says there is no default bandwidth limit for VPS, VDS, and dedicated servers, while noting that fair-use measures may apply to exceptionally high or disruptive traffic. The page lists port speeds from 100 Mbps to 1 Gbps for VPS/VDS. Those are provider-level policy and product statements, not a measurement of your individual server's throughput or proof that traffic was throttled. Check your own metrics and account status before drawing that conclusion.
Contabo's connection troubleshooting guidance identifies resource use and firewall or network configuration among possible contributors to instability. That makes CPU, RAM, bandwidth use, and network rules sensible things to inspect, not evidence that any one of them caused a particular stop. If the evidence points to a host or route issue, provide the provider with timestamps and diagnostics rather than attributing the failure from its duration alone.
A reboot can be a recovery or diagnostic step, not a root-cause fix. If the operating system remains accessible, Contabo Support advises considering a reboot from the operating system. Before rebooting, preserve logs and metrics where possible: transient evidence can disappear, and a reboot will not resolve a persistent source, credential, firewall, or routing problem.
Make a cause-specific change and retest
Choose one change based on the layer your evidence implicates. The table separates common observations from the next test; it is not a universal command recipe. FFmpeg version, input protocol, output protocol, and whether EOF should end the job all matter.
| Evidence | What to test | What it cannot establish |
|---|---|---|
| FFmpeg exited with an error | Inspect final log lines and exit status; correct the reported input, encoding, or write problem | That a restart policy will remove the underlying error |
| Input reads stopped or disconnected | Verify the source and protocol; consider input-side reconnect behaviour supported by your build | That publishing output will reconnect too |
| Input continues but output writes fail | Verify destination, key, protocol, and relevant output recovery support | That input reconnect settings can repair publishing |
| Process and traffic stopped during resource or network events | Compare system metrics, network configuration, and provider status at the recorded time | That Contabo caused the event without corroborating evidence |
For a process exit, supervise the process and test that logs capture both a failure and a subsequent launch. For an input fault, test the exact source protocol and decide how EOF should behave. For an output fault, validate the destination and relevant output recovery approach. For a VPS or network concern, change a measured bottleneck or configuration issue, then observe whether the same condition recurs.
Retest for a period that is long enough to exercise the conditions around the failure, but do not treat a shorter successful run as proof of a permanent fix. Preserve comparable logs and metrics. If the stream restarts from the beginning after a failure, decide whether that loss of position is acceptable; a restart is not necessarily continuity. For a prerecorded loop, test the loop and audio as well as the publishing path. A pre-publication YouTube lofi stream test offers a useful way to think about checking the complete viewing experience before relying on a setup.
If keeping a VPS command alive requires ongoing process and network diagnosis that you do not want to manage, StreamNeo can remove the need to keep your own computer running for a file-based YouTube channel: you upload the video and provide the stream key, while the broadcast is monitored and restarted if it drops. It is YouTube-only, and it does not make a failing source, rights question, or channel configuration problem disappear.
Escalate with useful evidence
If the failure appears to involve the VPS or its network, open a support request with a concise timeline. Include the date and timezone, the time the stream stopped, whether FFmpeg exited, the exit status, the relevant log excerpt, and what the process and network were doing immediately before and after. Attach CPU, memory, disk, and bandwidth observations for that interval, plus any firewall, interface, or route changes that may be relevant.
State the direction of the problem: for example, input packets stopped arriving, or output writes to the publishing destination failed. Identify the protocol and FFmpeg version, but redact stream keys, passwords, and private source URLs. Ask the provider to investigate the specific host or network evidence rather than presenting “it stopped after a few hours” as proof of cause.
If you contact YouTube or the source provider instead, give them the evidence relevant to their side: the scheduled stream, the time of the event, and whether FFmpeg continued to send output. Do not send the same broad VPS diagnosis to every party. A precise report shortens the path to the team that can actually inspect the failing layer.
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 stopping after a few hours mean Contabo is throttling my stream?
No. Runtime alone does not establish throttling or identify which component failed. Contabo's published guidance describes no default bandwidth limit alongside fair-use discretion, so compare your own traffic and server status with the provider's current information before concluding that a limit was involved.
Should I add FFmpeg reconnect flags?
Only after you identify a failed input and verify that the relevant option applies to its protocol and your installed version. Input reconnect options do not automatically recover a failed publishing output, and treating EOF as an error may be wrong for a finite file.
Will a service restart keep the stream running?
A service manager can relaunch FFmpeg after an unexpected process exit, but it cannot repair a persistent source, destination, credential, or network fault. If FFmpeg remains alive while output is stalled, an exit-based restart policy may not run at all.
Should I reboot the VPS when the stream stops?
A reboot may restore service or help test a suspected transient condition, but it does not identify or fix the root cause. Save logs and metrics first if possible, and follow Contabo Support's current reboot guidance when the operating system remains accessible.