A YouTube live stream that keeps reconnecting on Excitel broadband needs a fault boundary, not an assumption about the provider. Start with a wired connection and exact interruption times, then compare YouTube’s stream-health messages with encoder logs, CPU load, home-network status and sustained upload performance.
For a 24/7 channel, the aim is to identify what failed and make recovery less fragile. A single speed test or a backup encoder cannot establish that your internet path will remain available overnight.
Map the failure boundary before changing settings
A reconnect is a symptom, not a diagnosis. The stream can break because the encoder stopped producing output, the computer could not keep up, the local network dropped, mains power failed, the broadband connection was interrupted, or YouTube rejected an incoming format or setting. Several things can also happen together.
Make a simple incident log. For each interruption, note the local time and time zone, whether the encoder said it disconnected or restarted, what Live Control Room showed, whether the router or ONT lights changed, and whether other devices lost internet. Save encoder logs and a local recording if your setup can make one. These observations help correlate events; they do not by themselves prove which party caused a failure.
Use the same clock reference where possible. If your encoder logs use UTC and your notebook uses local time, record the offset rather than trying to remember it later. A timestamp such as “stream reconnected” is much more useful when matched against a YouTube health warning, a router status change or an upload test taken during the same window.
Separate the questions. Did the encoder continue sending a healthy picture? Did the computer still have a working local network? Did the router retain its internet connection? Did YouTube report an ingestion or configuration error? Answering these in order prevents an incorrect setting change from obscuring a line fault, or an ISP complaint from distracting you from an overloaded encoder.
Use Ethernet and record interruption times
For a controlled test, connect the streaming computer directly to the router with Ethernet if the equipment permits it. This removes Wi-Fi coverage, interference and roaming between access points as likely variables. A suitable cable can improve the local link, but it cannot repair a provider-side interruption, a damaged access line or congestion beyond your home.
Pause avoidable network use during the test: cloud backups, large uploads, software updates and other streams. YouTube notes that shared network use can reduce the bandwidth available to an individual stream. Its streaming tips also warn that a connectivity disruption can break a live stream. This is a reason to test your own network conditions, not evidence that any particular Excitel connection is faulty.
Keep the test representative. A quiet morning test may not reflect the evening hours when several people are watching video or uploading files. Record the time, whether the connection was wired, whether other household devices were active, and the upload result. If the issue happens only under shared load, that points to a different mitigation than a router that loses its WAN connection when the home is otherwise idle.
A download result is not a substitute for upload evidence. A plan advertised mainly by download speed does not tell you how much stable outbound capacity the encoder has at the moment it needs to send video. The bitrate trade-offs for YouTube Live matter here: raising output quality also raises the demand placed on the upload path.
Compare encoder logs, CPU and YouTube health
During the next interruption, look at the encoder first. Does its preview freeze or turn black? Does the log show an encoder restart, a rendering lag, a dropped connection, or an error opening the source file? Check CPU load and, where relevant, GPU load around the same time. A machine that is saturated by video encoding or other tasks can fail to produce a steady stream even while the internet connection remains available.
Then compare that evidence with YouTube Live Control Room. A message about bitrate, format, keyframes or a primary/backup mismatch suggests an ingestion configuration problem to investigate. A healthy local preview paired with a connection failure is a different pattern. YouTube’s encoder troubleshooting guidance recommends checking encoder health and CPU load, and then testing the outbound connection if the encoder appears healthy.
Do not treat “reconnecting” in the encoder as proof that the ISP is at fault. The software may be reacting to a temporary loss elsewhere, or its own process may have stopped sending data. Likewise, a healthy local preview does not prove the stream is reaching YouTube; it only helps show that the source and local encoding path are still producing a picture.
If you use OBS or another local encoder for a prerecorded loop, preserve enough evidence to reproduce the situation. A channel using a long playlist may have separate source or scene problems from the internet path; a guide to configuring OBS to loop a media playlist can help you check that part of the setup. Change one relevant variable at a time and note what changed, rather than applying several fixes at once.
Verify resolution, bitrate, codec and keyframes
Compare the active encoder profile with YouTube’s current guidance for the selected codec, resolution and frame rate. Settings are not universal: a 720p60 stream and a 1080p30 stream have different recommended bitrates, and other combinations differ too. YouTube’s live encoder settings list 5 Mbps for H.264 at 1080p30 and 6 Mbps for H.264 at 720p60. Treat these as examples from those specific profiles, not as a target for every stream.
For RTMP or RTMPS, YouTube recommends constant bitrate (CBR) and a two-second keyframe interval, with the interval not exceeding four seconds. It recommends RTMPS as the encrypted option. Check the Live Control Room message if it flags a format, bitrate or keyframe error; follow the error detail instead of changing settings at random. If a backup feed is configured, compare its settings with the primary where YouTube requires them to match.
The bitrate must also fit the sustained upload available to the encoder. YouTube recommends allowing 20% headroom and accounting for both primary and backup streams where applicable. That means a setting that matches YouTube’s format guidance may still be unsuitable if household use or a weak upstream leaves too little capacity. Reducing resolution or bitrate can lower the required upload, but may reduce picture detail; test the choice with your actual footage and viewing needs.
Keep a record of the working profile: codec, resolution, frame rate, bitrate mode, target bitrate, keyframe interval and any backup-stream settings. If you alter one value, check whether the health warning changes and whether reconnects continue. The point is not to find a magic setting, but to distinguish an encoder-format fault from inadequate or unstable delivery capacity.
Check sustained upload, home network and power
Measure upload on a wired connection at several times, and, if possible, while the stream is running. Compare those results with the total outgoing bitrate and leave the headroom YouTube advises. A brief test is only a snapshot: it can miss a short drop, contention at a busy time, or a loss that occurs overnight. Preserve the time and conditions with each result.
Look for local network evidence too. If Wi-Fi devices disconnect but the wired encoder remains connected, the wireless network may be a separate problem. If the router’s internet or WAN status changes at the same time as the stream, that is useful evidence for support. If all devices retain internet while only the encoder drops, inspect the computer, encoder software, cable and local router port before concluding that the broadband service failed.
Power can create a similar pattern. A brief mains interruption may reboot the router, ONT or encoder and produce a reconnect even if the access line itself is sound. Check whether router lights or device uptime reset around the incident. A UPS for the computer and network equipment may help if local power loss is the identified cause and the ONT is included; it will not keep an upstream provider network running through its own fault.
Provider-supplied ONT equipment has its own support and replacement conditions. Check with Excitel before replacing or modifying it. Excitel’s published terms describe plan speeds as best effort and variable with network conditions, customer equipment and Wi-Fi coverage. That is general wording about service conditions, not a finding about your particular line or location.
Escalate an upstream fault with evidence
Contact Excitel when your evidence points beyond the encoder and home network: for example, the encoder remains healthy, a wired test shows a connection problem, or router/ONT status indicates loss of WAN service at the same time as the stream interruption. Give support the registered account and service location through its published support route, plus exact timestamps and the conditions under which tests were made.
Ask for the line or ONT status and any area outage or repeated session drops that can be checked for the logged windows. Include wired upload results, whether other devices lost internet, and the router/ONT indicators you observed. Keep the complaint reference and the response. If you are asked to repeat a test, record its time and method so the result can be compared with the original incident.
Excitel’s customer care and grievance redressal page lists its support routes and a target for network or technical complaints. A published response target is not a guarantee of resolution, an uptime commitment, or confirmation that Excitel caused the reconnect. If the evidence instead shows YouTube flagged an ingestion setting, correct that setting first and retain the message in your notes.
Reduce the chance one interruption ends the broadcast
Continuity planning is about recovery, not a promise that nothing will fail. YouTube recommends preparing encoder events in advance, monitoring audio and video, and testing backup-encoder failover. Its live streaming checklist describes testing the backup by stopping the primary encoder or disconnecting its Ethernet cable. Run that test when you can monitor the result, and confirm that the audience-facing stream recovers as expected.
A backup encoder addresses some failures of the primary computer or encoding process. It does not replace a failed router, ONT or broadband path if both encoders use the same connection. A second, genuinely independent internet path could help with some access-link failures, but only if it is available at the site, has sufficient sustained upload, and its failover and stream-recovery behaviour have been tested. Do not assume that a phone hotspot or a second device will carry the stream reliably without measuring it.
Write down the recovery steps where someone else can find them: which encoder to start, which stream key or profile to use, what YouTube health state to expect, and whom to contact if the WAN is down. Keep primary and backup configurations aligned where required. A small local recording can preserve a copy of the programme content even when the live broadcast is interrupted, though it does not restore the live audience’s connection.
If the repeated burden is keeping a home computer running and watching it overnight, StreamNeo removes that specific local-computer dependency by turning an uploaded video into a YouTube live stream that runs with your computer switched off and is monitored and restarted if it drops. It is YouTube-only, and it still depends on a working YouTube connection on the broadcast side; it does not make a failing home broadband line reliable. For readers comparing approaches, the options for running prerecorded video around the clock are worth considering alongside a local encoder and tested network continuity plan.
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 reconnect prove Excitel is causing the problem?
No. A reconnect can come from the encoder, CPU load, home network, power, broadband path or YouTube’s ingestion checks. Correlate timestamps and wired-connection evidence before asking the provider to investigate a line fault.
Is a high download speed enough for a 24/7 stream?
No. The encoder depends on stable upload capacity, and household uploads can reduce what is available to it. Measure upload while wired, compare it with the total outgoing bitrate, and retain headroom rather than relying on an advertised download figure.
Will a backup encoder protect the stream during an internet outage?
Not if it uses the same failed internet path. Test encoder failover, then separately assess any backup connection for availability, upload capacity and recovery behaviour at the actual location.
Should I change bitrate whenever Live Control Room reports a problem?
Only when the message or your measurements point to bitrate or format as the issue. Check YouTube’s current encoder guidance for your codec, resolution and frame rate, and make one change at a time so you can see whether it addresses the fault.