If your YouTube live stream keeps disconnecting at night, first find out which connection closes: the encoder’s connection to SRS, SRS’s forward to YouTube, or a direct encoder-to-YouTube connection. The timing is useful evidence to compare with a stable period, but it does not by itself prove broadband congestion or throttling.
For an SRS relay, treat the two network legs separately; for a source publishing directly to YouTube, skip the SRS checks. Record the first failure and the messages from each system before changing settings, so you can distinguish a broken route from an encoder or stream-health problem.
Identify what disconnects first
Start by sketching the path from the video source to YouTube. If an encoder such as OBS publishes to SRS and SRS forwards the stream, there are two connections to investigate: encoder-to-SRS and SRS-to-YouTube. SRS describes these roles in its RTMP publishing documentation and forwarding documentation. Check the documentation for the SRS version you actually run; the pages cited here cover different versions, and directives or defaults may not match your deployment.
If the encoder publishes directly to YouTube, there is only one contribution connection to diagnose. Do not use SRS relay checks in that case: an SRS log cannot explain a direct path that does not include SRS. Write down the destination URL or endpoint, the stream’s configured route, and which device or process originates the upload.
At the next drop, note the exact time in UTC, how long the interruption lasts, whether the encoder says it is disconnected or reconnecting, and whether YouTube reports a health warning. For a relay, also note whether the encoder remains published to SRS while YouTube stops receiving the forward. A video that freezes at the viewer’s end is not enough to identify which connection failed.
A useful distinction is connection closure versus stream-health warning. If a connection closes or reconnects, investigate the relevant network leg, process and endpoint. If it remains connected but YouTube flags bitrate, frame rate, codec or keyframes, investigate stream configuration and incoming media. Both can happen together, so collect the timestamps rather than assuming one symptom rules out the other.
Check encoder-to-SRS publishing
For a relayed stream, begin at the encoder. Look for the publish start, any explicit disconnect, connection timeout, authentication or path error, and successful or failed reconnection. Then compare these events with SRS’s record of the incoming publisher. If both sides record the encoder connection closing at the same moment, focus first on the source computer, its local network and the path from the source to the SRS host.
If the encoder reports that it is still connected but SRS records the publisher disappearing, verify that both records refer to the same stream and time zone. Check the configured SRS address, application path and stream name, along with credentials where applicable. A mistyped destination or a changed configuration can look like intermittent loss if a process reconnects with a different target.
When the source remains on Wi-Fi, compare its behaviour with a temporary wired Ethernet test if that is practical. A wired test can help isolate the local wireless segment; it does not show that the broadband provider, SRS host or YouTube is at fault, and it is not a guaranteed cure. Avoid buying equipment before a comparison gives you a reason to test that part of the path.
For a direct-to-YouTube source, this section’s encoder checks still apply, but the endpoint is YouTube rather than SRS. Confirm the selected YouTube ingest destination and stream key, and check whether the encoder log shows the connection ending or media delivery continuing. Do not look for a publisher in SRS when the source bypasses it.
If your encoder uses FFmpeg, the sequence and reconnect messages matter as much as the final error line. The blog’s guide to FFmpeg restarting a playlist on a 24/7 stream can help distinguish a playlist or process restart from a network disconnect. Keep the diagnosis specific to the logs you have rather than treating every restart as evidence of a broadband problem.
Check SRS-to-YouTube forwarding
This section applies only when SRS relays the stream. If the encoder-to-SRS publish stays active during the interruption but YouTube stops receiving video, inspect the outbound forward as a separate connection. Check SRS logs for the forward target, connection attempts, closures and reconnections, and confirm that the target URL and credentials are still correct.
A stable incoming publisher does not establish that SRS can reach YouTube continuously. The relay host has its own outbound route, process state and resource use. Compare the time of a forward failure with any SRS process messages and with YouTube’s stream-health status. If the host logs show resource or process errors at the same time, investigate those alongside the network path rather than changing the encoder’s upload settings by default.
Confirm the configured outbound endpoint, application path and stream name against the current YouTube ingest details. For RTMPS, Google’s RTMPS ingestion guide explains the connection requirements, including use of TLS, port 443 and the correct hostname for SNI. A protocol, hostname or application-path mismatch can prevent setup or forwarding even where general internet access is available.
If the forward repeatedly reconnects, record whether each attempt reaches the same destination and whether it resumes without changing the encoder’s publish. That pattern can help separate an SRS-to-YouTube problem from a source-to-SRS interruption. Do not assume that a successful encoder publish means YouTube is receiving the stream; those are different observations on a relay.
Compare logs during failure and stable periods
A single failure log often lacks context. Collect the encoder log, SRS log if applicable, YouTube health message and network observations around the same time. Record the time zone or convert timestamps to UTC, the start and end of the interruption, whether each connection closed, and how it recovered. Keep an example of a stable period too, ideally from a similar time of day, so you can see what differs rather than merely what occurred once.
A simple incident record can keep the evidence aligned:
| What to record | During a failure | During a stable comparison |
|---|---|---|
| Encoder | Publish state, error text, reconnect time | Whether publish stays active |
| SRS, if relaying | Incoming publisher and outbound forward state | Whether both legs stay connected |
| YouTube | Exact health message and time | Health status and incoming-video state |
| Network | Upload, latency or loss observations and test method | Same observations using the same method |
| Local setup | Wi-Fi or Ethernet, device and any changes | Same details, noting any difference |
Compare the first event, not just the last error. If the encoder publish ends first and SRS records the incoming stream disappearing, that points you towards the source-to-SRS leg. If SRS continues receiving while its forward closes, concentrate on the relay’s outbound leg. If connections remain open but YouTube reports a stream-health issue, examine the arriving media and settings.
A stable period does not prove the failure is caused by a particular time-of-day condition. It provides a control for comparison. The evening and night may differ in household network use, Wi-Fi conditions, scheduled tasks, power state or other factors, but those are hypotheses until your own measurements or logs support them. Do not attribute a cause to an Indian ISP, city or broadband technology from the timing alone.
Measure network behaviour without assuming the cause
YouTube recommends testing upload bitrate and monitoring stream health in its live encoder guidance. Repeat measurements during the failure window and a stable period, using the same device and method where possible. Record upload capacity and any latency or packet-loss observations alongside the stream logs. A general speed test is useful context, but it does not necessarily measure the exact route or sustained performance of the stream’s connection.
For a relay, the source’s upload test describes the source-to-SRS side, not the relay host’s outbound path to YouTube. If the encoder remains published but forwarding fails, a speed test from the encoder cannot settle the question. Gather evidence from the SRS host or its operator for the outbound leg, and compare that with SRS’s own forward logs and YouTube’s health status. For a direct source, measure the source’s contribution connection to YouTube; there is no intermediate SRS leg to test.
Match the intended stream bitrate to the upload capacity you observe, with room for variation rather than treating a brief peak as sustained capacity. YouTube’s H.264 recommendations vary by resolution and frame rate: its current guidance lists 5 Mbps for 1080p at 30 fps, 14 Mbps for 1080p at 60 fps, 3 Mbps for 720p at 30 fps and 8 Mbps for 720p at 60 fps. These are platform recommendations for those formats, not a measurement or guarantee of what a particular Indian broadband connection can sustain overnight.
If a source uses Wi-Fi, comparing a temporary Ethernet connection with the same stream settings can help test whether the local wireless link contributes to the problem. Keep other variables steady where you can. A better result on cable narrows the investigation to the local connection; it does not establish that the cable fixed a fault elsewhere or that it will prevent future drops.
TRAI includes peak-hour network-link utilisation among broadband quality reporting measures. That is useful context for network-level reporting, not a diagnosis of an individual subscriber’s route, and it does not establish that a night-time drop is throttling. Treat claims about a specific provider or time window as unconfirmed unless the evidence identifies that path and condition.
Check YouTube stream health and configuration
Read the actual YouTube health message before changing bitrate or encoder settings. Google’s Live Streams health-status messages cover categories such as bitrate too high or low, frame rate, GOP or keyframe problems, codec issues and insufficient incoming video. The category helps you decide whether to adjust media settings or continue investigating a connection interruption; it is more useful than changing several settings at once.
YouTube recommends constant bitrate (CBR) and a keyframe interval of two seconds, not exceeding four seconds, in its encoder guidance. Check those values, the selected codec and the resolution and frame rate against the recommendation for your format. Change one relevant setting at a time and observe whether the same health message or failure pattern returns. A configuration recommendation does not demonstrate that a network path is stable, just as a good speed-test result does not rule out a keyframe or codec problem.
For RTMPS, verify the protocol, ingestion endpoint and application path, TLS, port 443 and hostname/SNI. The hostname is part of the authenticated connection setup. If the source or SRS target uses a stale or malformed URL, correct that before interpreting repeated connection failures as a night-time broadband event. Avoid sharing a stream key in screenshots or support logs; redact it while retaining the endpoint and error details needed for troubleshooting.
If the stream has no useful health message but incoming video becomes insufficient, correlate that report with the encoder and, when relevant, SRS forwarding timestamps. The blog’s bitrate and resolution troubleshooting guide addresses a related media-quality decision; a drop in the live connection still calls for identifying which connection closed first. For planning contribution capacity, see how upload speed relates to a continuous stream, while remembering that a relay introduces a separate outbound path.
Choose the next test from the evidence
Once you know which leg is implicated, avoid broad changes that make the next incident harder to interpret. If the source-to-SRS publish closes, test the source network and encoder path first. If the incoming publisher persists but SRS’s forward fails, check the relay’s outbound target, process and route. If both connections remain active but YouTube reports a media health issue, use that message to guide a focused settings check. For direct publishing, assess the source-to-YouTube connection and settings only; there is no relay diagnosis to perform.
If the cause remains uncertain, keep capturing comparable windows rather than declaring the ISP responsible because the interruption happens at night. A record with matching timestamps, logs and network measurements gives you something actionable to take to your broadband provider, SRS administrator or encoder support contact. Tell them which endpoint was affected and what remained stable, not only that the stream dropped.
For a channel that depends on an always-on broadcast, keeping a computer awake and manually restarting a failed encoder can itself be a source of overnight work. StreamNeo removes that specific need by letting you upload a video and have it run as a YouTube live stream while your own computer is off; it does not identify or repair an ISP, SRS or YouTube-ingest fault in an existing relay setup.
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 live stream keep disconnecting at night?
The time pattern tells you when to compare measurements, not what caused the drop. Check which connection ended first, compare the same logs and network observations with a stable period, and use YouTube’s health message to distinguish incoming-media problems from a connection closure.
How do I troubleshoot SRS forwarding to YouTube?
Check whether the encoder remains published to SRS while the outbound forward closes. If it does, inspect the SRS forward target, credentials, logs and outbound route, then compare those timestamps with YouTube health status; if the encoder publish also ends, investigate that separate leg as well.
What should I check if my encoder publishes directly to YouTube?
Skip SRS checks and inspect the encoder’s YouTube destination, connection log, stream-health message and upload measurements. Confirm RTMPS details and media settings if the connection is established but YouTube reports a health issue.
Does a night-time pattern mean my ISP is throttling the stream?
No. Timing alone does not establish throttling or congestion, and network-level reporting cannot diagnose your individual route. Collect time-correlated evidence from the affected connection before drawing a conclusion or asking your provider to investigate.