A disconnect alone does not show that Hetzner is at fault. Compare the time YouTube reports a stream problem with your encoder logs and server-side network evidence to find whether the failure points to configuration, outbound access, the route, or host resources.
First establish whether the encoder actually lost its connection or viewers only saw playback stop. The checks below help narrow the cause, but a specific diagnosis needs your server type, encoder, protocol, exact error and logs.
Start with the disconnect timestamp
Write down the time of each interruption in UTC, including the time zone used by your encoder or monitoring tools. Record whether the event happened as the stream started, after a similar running period, or at an apparently irregular time. A sequence of timestamps is more useful than a general description such as “it drops overnight”.
Also distinguish two different symptoms. If the encoder reports a lost connection or YouTube shows the incoming stream as interrupted, the sender-to-ingest path needs investigation. If the encoder remains connected and YouTube continues receiving video but viewers report buffering or a frozen picture, the issue may instead involve playback, the viewing device, or the viewers’ connections. Do not test the server’s ingest path as though those cases were the same.
Build a small event record for each occurrence:
| Record | What to note |
|---|---|
| Time | Exact UTC time, including seconds if available |
| Stream state | Starting, connected, reconnecting, or still connected |
| YouTube | Stream-health state and the exact message shown |
| Encoder | Log lines immediately before and after the event |
| Server | Service or container restart, CPU and memory observations, and network-interface events |
| Configuration | Protocol, ingest hostname and port, and any recent changes |
Keep the original wording of errors rather than translating it into a guess. For example, “connection timed out” is a clue about a connection attempt or response, while a message about an invalid SSL certificate points towards a different branch of checks. Neither phrase should be assumed unless it appears in your own records.
For a 24/7 channel, compare a failed event with an interval when the stream worked. Note changes in the file, encoder settings, service restarts, firewall rules or server load. If you are still deciding how a server-based loop should operate, the guide to streaming a Bengali playlist from a server gives useful operating context, but it cannot diagnose a particular disconnect.
Check YouTube Live Control Room messages
Open YouTube Studio’s Live Control Room and inspect stream health and the messages around the recorded time. YouTube’s stream-health metrics guidance explains the status information available while a live stream is running. Use the timestamp and exact status together: a red or degraded state tells you that YouTube detected a problem, but does not by itself identify whether it began at the encoder, on the way out of your server, or farther along the route.
Check whether YouTube’s view of the incoming stream changed at the same time as the encoder log. If both indicate a disconnect at 02:14 UTC, that is a stronger event correlation than a viewer message received minutes later. If the Control Room reports healthy input throughout, while only some viewers describe interruptions, preserve that distinction and check whether reports come from one device or from different networks.
YouTube’s troubleshooting guide recommends checking stream health, encoder status and the outgoing connection when a stream has problems. Follow those checks in that order rather than treating one dashboard message as a verdict about the hosting company. A Control Room message is evidence about YouTube’s ingest view, not proof of the cause upstream.
Copy down the ingest URL and protocol currently configured in the encoder, without sharing the private stream key. Confirm that the hostname and protocol match the configuration shown in the Live Control Room. Never put a stream key in a public support post or paste it into an untrusted diagnostic service. If you need to show configuration, redact the key first.
Read encoder logs for the same time
Find the encoder or streaming service log covering the disconnect timestamp. Look for a sequence, not just the final line: connection attempt, successful connection, dropped socket, reconnect attempt, process exit, or a repeated error. A service restart at the same moment may be important; so may a continuing encoder process that reports no network loss.
Check whether the process itself is stable. Compare CPU and memory observations at the event with the period before it, and look for an out-of-memory event, container restart, system service restart, or stalled encoder. YouTube’s troubleshooting guidance includes checking encoder load when diagnosing stream quality. Resource pressure is a possibility only when your own measurements or system records support it; a disconnect is not evidence on its own that a server ran out of capacity.
If you use FFmpeg, keep its standard output and error output around the event rather than saving only a service manager’s restart notice. Record the command or relevant settings, with the stream key removed. Look for whether input decoding continues while output transmission fails, whether the encoder exits, or whether it reports an error while establishing the connection. Those distinctions tell you which next check is relevant.
Compare startup failures with mid-stream failures. If the stream never connects, prioritise the URL, protocol, port, credentials and outbound policy. If it runs and later drops, examine recurring service events, changing network conditions, load and any scheduled job that coincides with the timestamp. This is a sorting method, not a rule: a startup failure can still be caused by a route or service problem, and a mid-stream failure can still reflect a bad configuration.
For repeated-file channels, a loop transition can also coincide with an encoder issue if the input or playlist process stalls. Compare the media transition time with the log time. The article on replaying the same video file all day discusses the loop design question; here, use the logs to determine whether the encoder remained connected through a transition.
Test outbound connectivity and Cloud Firewall rules
If the encoder appears healthy but YouTube loses its incoming feed, test from the server towards the actual YouTube ingest host and port configured in the Live Control Room. Do not substitute a generic speed test for this. A speed test measures a different destination and moment, and a result from one short test does not establish that the encoder’s route remains usable through a night-long broadcast.
Run a controlled connection check using tools appropriate to your operating system and encoder, and record the destination, port, result and time. If the error recurs predictably, keep the test evidence near that interval. Avoid repeatedly starting a second encoder against the same channel unless you understand the effects on the live session. A successful connection check is useful, but it does not prove that a long-lived stream will remain stable or that bitrate fits available capacity.
If the machine is a Hetzner Cloud server, inspect its Cloud Firewall rules as well as the operating system firewall. Hetzner documents that when no outbound rules are defined, outbound traffic is allowed; when outbound rules are defined, unmatched outbound traffic is denied. Confirm that the rule set permits the configured destination and port. This behaviour is specific to the Cloud Firewall documentation and should not be casually applied to a dedicated server or another product’s firewall.
Compare the effective rules with the event timeline. A recent rule change, a rule attached to the wrong server, or a policy that allows one port but not the configured port are concrete things to verify. If the configuration has not changed and outbound checks succeed during the event, preserve that result and move to route and resource evidence instead of repeatedly editing firewall rules without a reason.
For RTMPS, use the RTMPS endpoint copied from the Live Control Room rather than assuming that an older RTMP URL is still appropriate. YouTube describes RTMPS streaming as a secure extension of RTMP. If your matching error concerns an SSL certificate, verify both the protocol and hostname. YouTube identifies port 443 as a troubleshooting step where the encoder allows it. These checks apply to RTMPS and a relevant SSL or timeout error; they are not a universal fix for every dropped stream.
Check the route to YouTube and host resources
A route issue is a possibility only when evidence points that way. If your outbound test fails, repeat it with the precise host and port and retain the result. If it succeeds while the stream still disconnects, record the success too; a single successful check may not cover the exact failure window, but it can help rule out a persistent block.
Where packet loss is suspected, use MTR or WinMTR evidence carefully. Loss reported at an intermediate hop but absent at the destination can reflect routers that do not answer ICMP probes consistently; it does not establish end-to-end loss. Loss that continues through the destination is more relevant and deserves investigation. Hetzner’s network troubleshooting guidance asks for bidirectional traces with at least 200 packets for packet-loss reports. Follow the current instructions for the server product you use.
Save both directions when possible, with start and end times, destination and packet count. A trace to your server is not interchangeable with a trace from your server towards the ingest endpoint. Hetzner’s guidance also makes clear that a vague report such as poor ping is not enough for network analysis. Include the evidence through the appropriate support request route and identify the affected server. If the evidence indicates the issue lies beyond Hetzner’s network, the responsible network provider may also need to investigate.
At the same time, compare host observations with the timestamps: CPU load, memory use, disk pressure if relevant to the input file, network-interface errors, service restarts and operating-system firewall logs. Do not infer faulty hardware or a resource limit from a correlation-free symptom. If the machine continues to process the input and has no restart or pressure event while the socket drops, that shifts attention towards connection configuration or the network path, but it is still not a diagnosis by itself.
Check stream configuration against sustained outbound capacity, not just a peak result. YouTube advises choosing a bitrate suitable for a reliable connection and testing with representative movement and audio while watching stream health. Its encoder recommendations specify a two-second keyframe interval and advise not exceeding four seconds. These are YouTube recommendations, not proof that a particular bitrate or keyframe setting caused your event. The right bitrate depends on your output settings and measured capacity.
For an example tied to a stated connection size, see the 4 Mbps upload bitrate discussion. Do not copy its number into a different server or route without testing: the advertised or measured capacity is not necessarily the sustained capacity available to your stream. If audio continues while video transmission becomes unstable, check whether the selected video rate leaves adequate room for audio and network variation.
Narrow the cause with the exact error and setup
Once the evidence is assembled, classify the event by what failed first. This table is a way to choose the next test, not to assign blame from a symptom.
| Evidence at the recorded time | Next check |
|---|---|
| Encoder exits or service restarts | Process logs, service configuration, system events, CPU and memory records |
| Encoder stays up but output reports connection failure | Exact ingest URL, protocol, port, outbound firewall policy and a timed connection check |
| RTMPS SSL or certificate message | Confirm RTMPS scheme and hostname from Live Control Room; check port 443 if supported |
| Control Room input remains healthy while viewers report pauses | Separate viewer playback reports from sender-to-YouTube ingest evidence |
| Intermediate MTR hop shows loss but destination does not | Do not treat the hop alone as end-to-end packet loss; repeat and retain the full trace |
| Loss reaches destination or host-to-ingest checks fail | Preserve timed, bidirectional evidence and raise a specific network support request |
Before contacting support, collect the server type (Cloud or dedicated), region, operating system, encoder and version, protocol, ingest hostname and port, exact error text, UTC event times, relevant log excerpt, firewall rules and network test output. Redact stream keys and other credentials. This packet lets support investigate a bounded event rather than guess from “my stream disconnects”.
If the stream keeps failing after a setting change, change one thing at a time and record what changed and when. Otherwise, a later successful run will not tell you whether the cause was an endpoint correction, a firewall rule, a bitrate adjustment or a transient event. Keep a known-good configuration copy so you can restore it if a test makes matters worse.
For channels that cannot depend on a home computer remaining on, a managed broadcast can remove the specific burden of keeping a local encoder machine running and restarting it after a drop. StreamNeo takes an uploaded video and runs it as a YouTube live stream after you provide your stream key; it is YouTube-only. That changes who operates the broadcast, not the need to use the correct file and channel settings or to investigate a YouTube-side message.
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 a disconnect prove Hetzner is at fault?
No. The same symptom can arise from the encoder, endpoint or protocol configuration, outbound firewall policy, route, host resources, or a viewer-side playback issue. Use matching timestamps and evidence from both YouTube and the server before identifying a fault domain.
What should I check first if YouTube says “connection timed out”?
Confirm that the encoder is using the current ingest hostname and protocol shown in Live Control Room, then check outbound access to its configured port. If you are using RTMPS, verify the RTMPS URL and, where the encoder permits it, check the documented port 443 step. The exact error and logs still matter; a timeout alone does not identify the cause.
Why do I see packet loss on one MTR hop but not at the end?
Intermediate routers may limit or ignore ICMP responses, so an isolated hop showing loss while later hops and the destination do not is not proof of end-to-end loss. Preserve the full trace and compare both directions. Loss that continues to the destination is more useful evidence for investigation.
What details should I send with a support request?
Include the server product and identifier, UTC timestamps, encoder and protocol, exact YouTube message, relevant encoder and system logs, firewall configuration, and timed connectivity or MTR results. Redact the stream key. A specific, reproducible event with evidence is more actionable than a general report that the stream drops.