A YouTube stream stopping after a few hours does not, by itself, show that Hetzner caused the interruption. To fix it, first match the stop time against your encoder logs, YouTube Live Control Room messages and VPS metrics; then investigate the layer those records point to.
The key distinction is whether the encoder process exited, stayed up but lost its connection, or continued sending while YouTube reported an ingest problem. A VPS or route interruption is another possibility, but it needs evidence of its own. Preserve the records before changing settings, so you can tell whether a fix addresses the cause or merely changes the symptoms.
Record the stop time before changing anything
Write down when viewers first saw the stream stop, using UTC if your server and account records show different time zones. Also note what YouTube showed: ended, offline, waiting for encoder input, or still live with a health warning. Those states are clues, not diagnoses. A viewer noticing a frozen image later than the actual disconnect can otherwise leave you comparing the wrong log entries.
Keep the stream URL or broadcast identifier, encoder name, VPS name and the time range around the failure in the same incident note. Save a copy of the encoder log and relevant service or process-manager records before restarting the job or rotating a key. If you use a local recording, check whether it grew through the failure time and whether its ending is readable. YouTube's guidance also recommends checking the integrity of a local archive when investigating a stream problem (YouTube's live-stream troubleshooting guidance).
A simple timeline is enough to start. For example: at 02:14 UTC the public player stopped updating; at 02:15 the Live Control Room changed to waiting for encoder input; at 02:15 the FFmpeg log ended, while the service log recorded a restart. That pattern points towards an encoder or process-management issue. If the encoder log continued and reported dropped frames instead, the next investigation is different.
Do not treat a missing archive as proof that the live broadcast stopped at an archive limit. YouTube says streams exceeding 12 hours may not be captured as archives; this is an archival caveat, not evidence that YouTube automatically ends a live stream after a few hours (YouTube's archive guidance). An archive that is absent or incomplete and a broadcast that went offline are separate symptoms. Record each one separately.
Find out whether the encoder process exited
Check the process itself at the failure time, not just whether it is running now. A process may have exited and then been restarted automatically, leaving the channel live again while concealing the original event. Look for a clean end, a crash, a signal, an explicit encoder error, or a restart record. If you run FFmpeg under a process manager, inspect that manager's logs as well as FFmpeg's own output. With OBS or another encoder, find its logs and note whether they end abruptly or report that streaming stopped.
A running process is not proof that video was reaching YouTube. The software can remain open while its connection drops, its output stalls, or frames are discarded. Conversely, a service manager restarting a process is not proof of a host fault: the trigger might be an application error, a configuration issue, or an intentional restart policy. Keep the distinction clear in your notes.
If a prerecorded programme is supposed to resume after a reboot, compare the restart record with the steps in this guide to keeping a prerecorded stream running after a server reboot. It can help you think about what should happen after a restart; it does not establish that rebooting caused this particular failure. For an FFmpeg setup, the cron-job walkthrough is useful context for how a scheduled process is launched, but a scheduled relaunch is not a substitute for finding why the prior process ended.
If you have no logs covering the time of failure, add logging before the next test rather than guessing. Capture the encoder's standard output and error, the process exit status where available, and service-manager events with timestamps. Keep the existing command and configuration too. Changing the launch command and retry policy together can make a later failure harder to interpret.
Compare encoder logs with YouTube health messages
Open Live Control Room and compare its stream health and messages with the encoder log at the same time. YouTube recommends monitoring stream health during a broadcast (YouTube's stream health guidance). A message about encoder input, a stream-key error or a health warning has different implications from an encoder process that vanished with no corresponding YouTube message. Save the message text and the time it appeared; do not rely on a recollection after restarting the stream.
Use the evidence to sort the failure into a working category:
| What the records show | First area to investigate | What it does not prove |
|---|---|---|
| Encoder exited or logged an error; YouTube then waited for input | Encoder, its configuration, or process management | That the VPS host failed |
| Encoder remained active; logs show dropped frames or a disconnect | Connection route and whether the bitrate can be sustained | That YouTube rejected the stream |
| Encoder remained active; YouTube reports an ingest or key error | Current ingest URL, stream key and encoder configuration | That rotating a key fixes every midstream stop |
| Encoder and YouTube records change alongside VPS or network evidence | VM, host or network interruption | Which party or component caused it without more evidence |
| Public stream ended, but encoder and health records are unclear | Collect more evidence on a controlled test | Any particular root cause |
The table narrows the next check; it is not a verdict. A key or URL deserves attention when the observed message points there. YouTube's troubleshooting guidance suggests obtaining a new key and updating the encoder for certain encoder start errors (YouTube's encoder-error guidance). That is not documented as a universal remedy for a stream that ran successfully for hours before stopping. Confirm the current key and ingest URL in Live Control Room before replacing anything.
A stream that has been broadcasting for hours and then stops is not equivalent to one that cannot start. Avoid copying a fix for a start-up failure into a different situation without matching the error. If you need to understand how an encoder is expected to connect in the first place, use the FFmpeg YouTube setup guide alongside the current YouTube instructions, but let the actual health message guide the diagnosis.
Review CPU, memory, disk and network evidence
Compare server metrics from the minutes around the stop with the encoder and YouTube timeline. Look for CPU pressure, memory exhaustion, process termination, disk space or write errors, and changes in network traffic. A chart that covers a whole day may hide a brief event. Use the most detailed history you have, and note gaps: no recorded spike is not proof that none occurred if the metrics were sampled too coarsely or stopped collecting.
CPU pressure can coincide with encoding falling behind, but do not infer that from a busy-looking graph alone. Check whether the encoder logged missed deadlines or output trouble at the same time. If the system uses hardware encoding, confirm that the intended device was available and that the encoder did not report an initialisation or runtime error. An encoder failure points to the application or its operating conditions; it does not automatically identify a fault in the provider's host.
Memory evidence is more useful when tied to an event such as an out-of-memory kill or a process exit. Check the operating system's event records as well as the current memory display. Similarly, a full disk matters if the encoder writes a local recording, log or temporary file there, but it may be irrelevant to a stream that sends output without writing those files. Check the actual paths used by your job rather than assuming every stream writes to the same place.
For network evidence, compare outgoing traffic and connection errors with dropped-frame messages. A sudden loss of outbound traffic at the same moment as a process exit has a different meaning from traffic continuing while YouTube reports instability. If OBS is your encoder, OBS explains that dropped frames indicate an unstable connection to the remote ingest server or one that cannot sustain the selected bitrate; excessive drops can disconnect the stream (OBS stream connection troubleshooting). That points first towards connection stability and bitrate, not a specific host as the cause.
Where possible, compare the configured bitrate with what the connection can sustain over time, not just a short speed test. A brief test can look healthy while congestion or packet loss appears later. Check whether the issue repeats at the same bitrate, on the same route and during the same part of the day, but change one variable at a time. For more on the distinction between a displayed resolution and what viewers receive, see this explanation of why a YouTube gaming VOD can show a lower resolution; resolution symptoms are useful context but do not establish the cause of a disconnect.
Check the host, route and configuration
Only move to a provider or network hypothesis when the timeline supports it. Check Hetzner's status information for an incident that overlaps the interruption, and compare it with VM metrics and any network errors you recorded. An incident at the same time is relevant evidence, but it still may not explain a process exit or a local configuration error. If there is no matching incident, that alone does not prove the host and route were uninterrupted.
Hetzner's Cloud and vServer terms describe how availability is defined and include exclusions for certain failures attributable to customer software or configuration and some network interruptions beyond Hetzner's control (Hetzner's Cloud Server terms). Terms describe the service agreement; they cannot diagnose an individual stream. Do not take an availability commitment as a promise that a particular YouTube broadcast will remain connected, and do not cite the terms as proof that Hetzner was or was not responsible.
Check your own configuration for changes near the failure: an edited launch command, renewed credentials, a changed firewall rule, a scheduled maintenance task or a process-manager restart. Look for overlap in time, not just the fact that such a setting exists. Confirm the machine's clock and time-zone handling too. If server events use local time while YouTube shows another time zone, an apparent mismatch may be a conversion error rather than evidence of separate events.
Review the route and encoder settings against YouTube's current guidance. YouTube's encoder recommendations include constant bitrate, a recommended two-second keyframe interval (not exceeding four seconds), and RTMPS for encrypted ingestion; check the current YouTube encoder setup instructions and test the exact configuration before relying on it. These are settings to validate, not an explanation for every stream that ends after a few hours. Avoid changing several values at once, or you will lose the ability to tell which change mattered.
For a looping video, keep the playback and launch mechanism in view as well as the network path. A job can reach the end of its input or encounter a looping error while the VPS remains healthy. The FFmpeg cron-job guide can help you review how the process is started, while YouTube's health state helps establish what the platform saw. Neither one replaces the timestamp-by-timestamp comparison.
Choose a fix that matches the evidence
If the encoder exited, address the error in its log first. Correct a malformed command, missing input, inaccessible file or encoder error only when the record identifies it. If a process manager restarted the job, establish why it exited before tuning restart behaviour. Automatic retries can restore a stream after a transient fault, but repeated restarts can also hide a persistent error and create a cycle viewers experience as repeated outages.
If the encoder remained active and dropped frames or disconnected, test the route and bitrate. Reduce the selected bitrate only if your sustained connection cannot support it, then run a controlled test long enough to observe the same sort of conditions. Check packet loss and connection interruptions if you can measure them. Preserve the original configuration so you can reverse a change that does not improve the evidence.
If YouTube reported an ingest or key problem, verify the stream's current URL and key in Live Control Room, then align the encoder configuration with it. Rotate a key when the message or YouTube's instructions call for that action, not as a ritual after every interruption. If you change a key, confirm that the encoder uses the new one and that no other running job is still using an outdated value.
If the host or network evidence points to an interruption, collect the relevant timestamps, metric graphs and status information before contacting the provider. Ask a question tied to the observed interval rather than declaring a cause. Moving to another VPS is a reasonable test only when the current host or route is implicated and you can compare the same workload and settings; it is not a dependable first response to an unexplained stop.
A managed workflow can remove the need to keep your own computer on for a file-based channel, but it cannot tell you retrospectively which layer caused an earlier failure. StreamNeo can be useful when the specific burden is keeping a local computer running for an uploaded video stream; it does not make YouTube's health messages or your stream-key checks unnecessary. For a channel that depends on a custom FFmpeg process, direct access to its logs and runtime configuration may be more useful than moving to a workflow that does not expose that process.
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
Why does my YouTube stream disconnect after a few hours?
The duration alone does not identify a cause. Match the encoder log, Live Control Room health messages and server metrics at the exact failure time to distinguish a process exit, connection problem, ingest issue or host/network interruption.
Is my OBS stream dropping frames, or is the server restarting?
Check whether OBS remained active and logged dropped frames, then compare those timestamps with process-manager and VPS records. Dropped frames point towards connection stability or bitrate; a process exit or restart record points to a different layer and needs its own explanation.
Does YouTube stop a live stream at 12 hours?
The cited YouTube guidance says a stream longer than 12 hours may not be captured as an archive. That is an archive limitation, not a statement that YouTube automatically stops a live broadcast at that point, and it does not explain a stop after only a few hours.
Should I replace the VPS or rotate my stream key?
Neither is a general fix. Consider a VPS change when records implicate the current host or route, and check or rotate a key when YouTube's message or current instructions point to an ingest credential problem. If the evidence is unclear, preserve logs and run a controlled test before making either change.