A 24/7 YouTube stream that keeps reconnecting has a symptom, not yet a diagnosis. Check OBS connection and dropped-frame status alongside YouTube Live Control Room health messages, then test configuration, upload capacity, network and route evidence one factor at a time.
A reconnect alone does not show whether the encoder, local connection or path to YouTube is responsible. The useful fix is the one supported by what both OBS and YouTube report, not a setting change made on guesswork.
First identify what is reconnecting
Write down what you see and where you see it. OBS may show that it has lost or is trying to restore its connection to the streaming server; YouTube Live Control Room may show a stream-health warning or indicate that the incoming stream is not healthy. Those are related observations, but they are not interchangeable diagnoses.
Note the time of each reconnect, whether the picture freezes or disappears for viewers, and whether OBS reports dropped frames before or during the event. If the broadcast is a prerecorded loop, check whether playback continues locally while the connection indicator changes. A playback or media-file issue is different from an encoder-to-YouTube connection issue. For loop behaviour in OBS, see how to keep a loop from showing a black frame.
Keep an incident note rather than relying on memory. A simple record might read: “02:15 UTC, OBS dropped frames rose, reconnect followed; Control Room warning: insufficient video.” Record the exact words of the warning, not a paraphrase such as “YouTube error”. This makes it easier to compare repeated events or give useful detail to support.
Avoid changing bitrate, encoder, router and stream software at once. A stream that reconnects after several simultaneous changes does not tell you which change mattered. First capture the state as it is, then make one controlled adjustment that responds to evidence.
Check OBS dropped frames and connection status
While the issue is happening, open OBS’s status area and watch the dropped-frames counter and connection indicator. OBS explains that dropped frames mean the connection to the remote server is unstable or the stream cannot keep up with the configured bitrate. If enough frames are dropped, OBS may disconnect from the streaming server. Its stream connection troubleshooting guidance describes this distinction.
If the counter rises around the same time as the reconnect, the connection or the bitrate’s demands deserve attention. That observation does not, by itself, identify whether the cause is Wi-Fi, a busy upload connection, network equipment, an ISP route or a setting. It does make a first test more targeted: compare the configured bitrate with sustained upload performance, and consider a wired path if the machine is on Wi-Fi.
If OBS appears stable and the dropped-frame count does not rise, do not immediately lower bitrate as a reflex. Check YouTube’s health panel and the stream configuration next. A clean OBS counter is useful evidence, but it cannot rule out every network or configuration problem.
OBS says dropped frames are extremely unlikely to be caused by OBS Studio itself. Treat that as guidance about where to investigate first, not as proof that OBS cannot have software issues. If the evidence remains inconsistent, retain logs and note the OBS version and operating system before escalating.
Read YouTube Live Control Room health messages
Open the live stream’s health panel in YouTube Live Control Room and read the message as written. YouTube’s stream-health feedback can point towards an encoder configuration issue, or towards the quality and continuity of the incoming video or audio. Match its warning to the event time you recorded in OBS. YouTube’s live encoder settings guidance also advises testing before a live event and monitoring stream health while it is running.
The YouTube Live API health-message reference documents categories including bitrate, codec, keyframe frequency, missing or insufficient video, audio, and mismatched primary and backup streams. For example, videoIngestionStarved means YouTube is not receiving enough video for smooth streaming. A gopSizeLong message indicates keyframes are being sent less often than the allowed interval. These messages point to different checks; do not treat them as synonyms for “internet problem”.
A warning about missing video is not automatically proof of low upload speed. Check OBS and the encoder output at the same timestamp, then compare the warning against the configured stream settings. Likewise, a codec or keyframe warning calls for a configuration check even if the local connection indicator looks normal.
If you do not see a health warning, note that too. It may mean the available evidence is inconclusive, not that the stream has no problem. Keep the time record and compare what viewers report with OBS’s status and any new messages in Control Room.
Compare encoder settings with current requirements
Use YouTube’s current settings for the codec, resolution and frame rate you actually send. Its guidance covers multiple ingest codecs, so avoid applying an old blanket rule such as “all YouTube streams must use H.264” without checking the current table and the encoder’s chosen format. For RTMP or RTMPS, YouTube lists constant bitrate (CBR) and recommends a two-second keyframe frequency, with a maximum interval of four seconds. Follow the relevant settings for your ingest format and the message YouTube reports.
The bitrate figures below are YouTube’s published recommended ranges, not speed-test results or a promise of what a particular connection can sustain. YouTube’s page was accessed in September 2026; check it again before changing a long-running channel’s configuration.
| Output format | Codec | Published bitrate range |
|---|---|---|
| 1080p at 60 fps | H.264 | 6 Mbps minimum; 17 Mbps recommended |
| 1080p at 60 fps | AV1 or H.265 | 4 Mbps minimum; 12 Mbps recommended |
| 1080p at 30 fps | H.264 | 5 Mbps minimum; 14 Mbps recommended |
| 1080p at 30 fps | AV1 or H.265 | 4 Mbps minimum; 10 Mbps recommended |
| 720p at 60 fps | H.264 | 3 Mbps minimum; 8 Mbps recommended |
| 720p at 60 fps | AV1 or H.265 | 2 Mbps minimum; 6 Mbps recommended |
| 720p at 30 fps | H.264 | 3 Mbps minimum; 8 Mbps recommended |
| 720p at 30 fps | AV1 or H.265 | 2 Mbps minimum; 6 Mbps recommended |
These are recommendations for the outgoing stream’s encoding, not a claim that every connection delivering the same speed will be stable. The available upload needs to support the stream over time, including when other people or devices use the same connection. A single result from a speed-test site does not reveal whether upload stays steady throughout the evening or overnight.
Check the actual OBS output settings against YouTube’s table: bitrate, codec, resolution, frame rate and keyframe interval. If Control Room identifies a mismatch, correct that specific setting and test again. If you run primary and backup feeds, check that the relevant parameters match; YouTube’s health reference identifies mismatches as a configuration issue.
Test upload capacity and network stability
If OBS reports rising dropped frames, compare your stream bitrate with sustained upload capacity rather than relying on the internet plan’s advertised download speed. Run more than one upload check at different times, including a time when the stream usually reconnects. Observe whether other household or business devices are uploading large files, backing up photos, or making video calls. Shared upload capacity can vary even when you have not changed OBS.
When reducing bitrate to troubleshoot dropped frames, OBS suggests 75% of total upload speed as a starting point. This is OBS’s troubleshooting suggestion, not a YouTube requirement or a guaranteed safety margin. If your measured upload varies, a bitrate below a favourable one-off reading may still be needed for a useful test. Lowering output resolution or frame rate can also reduce what the connection must carry, but it changes the viewer experience; make that trade-off deliberately.
If the encoder uses Wi-Fi, test with Ethernet before buying replacement equipment. A wired connection removes Wi-Fi from the path as a variable, but it does not prove that a reconnect will stop: the router, modem, ISP or route to YouTube may still be implicated. Check that the cable is seated and that the network link remains active. Replace a cable only if it is damaged, loose or otherwise suspect.
Restarting modem and router can be a reasonable controlled test, but record the time and avoid doing it during a critical broadcast unless a brief interruption is acceptable. Check cables and network devices between the encoder and router. If security software, a VPN or bundled network-optimisation tool is present, isolate its effect one at a time and restore the normal setup if the test makes no difference. OBS also identifies outdated network drivers as a possible factor.
Change one variable at a time
Treat every change as a small experiment. Write down the original value or condition, change one thing, then observe for long enough to see whether the usual reconnect pattern recurs. A test that ends after a few quiet minutes may not tell you much about a problem that normally appears during a busy evening or overnight period.
A practical order is to act on the strongest evidence first:
- If OBS dropped frames rise, test a lower bitrate while keeping other settings unchanged.
- If the machine is on Wi-Fi, test Ethernet without changing bitrate or encoder settings.
- If YouTube flags a codec, bitrate, keyframe or feed mismatch, correct that named configuration item.
- If local changes do not explain the event, test one potential interference source, such as a VPN or security tool, and record the result.
Do not combine a codec change, router restart and bitrate reduction into one “fix”. If the stream improves, you will not know which adjustment helped; if it gets worse, you will not know what to reverse. Keep a short change log with the start time, the single change and the results from both OBS and Control Room.
For a channel built around continuous prerecorded material, also distinguish connection reliability from the workload of the playback device. Your computer still has to encode and send the stream if it is the broadcast source. If the recurring burden is keeping that computer running, moving a YouTube loop stream from OBS to a cloud service addresses that operational question, but it does not diagnose a bad bitrate or a YouTube health warning. StreamNeo can remove the need to leave your own computer running for a file-based continuous broadcast, but OBS and YouTube evidence still matter when you are diagnosing a source stream that reconnects.
Observe results and escalate unresolved issues
After each test, compare the same evidence you recorded before it: dropped frames, OBS connection status, Control Room health messages and event times. If a lower bitrate is followed by stable OBS status and fewer reconnects under comparable conditions, that supports the connection-capacity hypothesis; it does not prove that the same setting is right for every time of day. If the warning remains unchanged, restore the original setting before testing another factor.
If the local path appears stable but reconnects continue, contact your ISP with the event times and explain that the problem is sustained outbound streaming, not just slow downloads. Ask whether they can investigate interruptions or congestion along the route. ISP-side conditions can be outside your control, and an ordinary speed result may not capture a brief route disruption. Provide OBS logs and exact YouTube health messages where support asks for them.
If YouTube’s health panel names a configuration issue, use the current official settings and health-message pages before asking encoder support to interpret it. For issues that only appear in a particular playback or playlist workflow, compare the encoder and network evidence with your source workflow; preparing playlist videos for YouTube with different encoder options may help you separate file preparation from live transmission.
A 24/7 schedule makes a test window and monitoring plan important, but it does not create a special encoder setting. If you cannot keep a local machine available to observe the stream, choose an operating arrangement that provides monitoring appropriate to your workflow.
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 mean my internet is too slow?
Not necessarily. Rising OBS dropped frames can indicate an unstable connection or that the set bitrate is too demanding, but YouTube may instead report a configuration issue. Compare both sources of evidence before changing settings.
Should I lower bitrate first?
Only if the evidence points towards connection capacity, such as dropped frames rising near the reconnect. OBS suggests 75% of total upload speed as a troubleshooting starting point, not a universal rule; test one bitrate change and watch what happens.
What do YouTube stream-health warnings tell me?
They identify categories to investigate, such as bitrate, codec, keyframe frequency, insufficient video or a primary and backup feed mismatch. Use the message text and YouTube’s current documentation to choose the next check rather than guessing.
Is a wired connection a guaranteed fix?
No. Ethernet removes Wi-Fi as one possible variable, but a reconnect may involve another part of the local network or the route to YouTube. Test it as one change, then compare OBS status and Control Room health messages.