An encoder reporting that it is streaming does not, by itself, mean viewers can watch your YouTube event. Start by opening the intended event in Live Control Room and checking whether YouTube has received a preview, what the stream-health message says, and whether the event still needs a publication action.
The checks below follow that distinction: first confirm the destination, then inspect ingest and the event’s go-live settings, and only then change encoding or network settings. The correct go-live sequence depends on how the event was configured, so do not assume every stream should be started in the same way.
An encoder connection is not a published event
The encoder and YouTube are reporting different parts of the process. The encoder can establish a connection and send audio and video to YouTube; YouTube then receives and evaluates that feed, and the event has its own state and publication controls. A green or active indicator in OBS or another encoder is evidence about the encoder’s connection, not conclusive evidence that your channel’s event is available to viewers.
Open YouTube Studio and select the event in Live Control Room while the encoder is running. Look for an incoming preview and the stream-health indicator. If there is no preview, concentrate on the path from encoder to YouTube: the selected server or URL, the key, protocol, and any health error. If the preview is visible but the audience cannot watch, stop changing bitrate for the moment and inspect the event state and its controls.
This is also how you distinguish a stream that is delayed from one that has not been published. YouTube describes latency as the delay between the encoder capturing an event and that event appearing in the stream. A delay may mean viewers see the feed later; it does not explain away an event that remains unpublished. Check the state shown for the event rather than treating a few moments of waiting as proof of failure.
Write down the exact wording and timestamp of any health message before changing anything. A generic symptom such as “waiting for data” can have several causes, while a specific message points to a particular setting. YouTube’s stream health errors guide describes categories including encoding format, bitrate, keyframes, stream configuration and resolution. Correcting a named issue is more useful than changing unrelated encoder settings all at once.
Select the intended YouTube event
A correct feed sent to the wrong event can look like a publishing problem. In the encoder, check which stream URL or server and stream key are in use; in Live Control Room, confirm the event you are inspecting is the one those details belong to. This matters when you have separate test and public events, a scheduled broadcast, or more than one channel involved in your routine.
YouTube’s live encoder setup guidance explains how to obtain the stream settings for a broadcast. Compare the destination and key against the settings shown for the intended event, rather than relying on an old saved profile or a label in your encoder. The URL identifies where the feed is sent, while the key is the credential YouTube uses to accept it. Keep the key private; do not post it in a forum, screenshot, or support thread.
If a key has been reset, the encoder may still attempt to connect using the old value. Copy the current key from Live Control Room and update the encoder before retrying. YouTube’s troubleshooting advice also recommends trying a new stream key for certain startup errors in third-party encoder software. A key change is not a universal fix, however: if the event already shows a preview and a clear health state, inspect the event’s publication settings as well.
If your encoder signs in to YouTube directly rather than using a key, the issue may be with the encoder’s compatibility or sign-in path. Follow that software’s support guidance and confirm it is current. For a key-based workflow, record which saved encoder profile you changed so that a later restart does not quietly restore an old destination or credential.
Check incoming preview and stream health
The preview is the first practical dividing line. If it never appears, YouTube may not be receiving the intended feed, or the feed may be arriving with a problem that prevents proper processing. If it does appear, the encoder-to-ingest path is at least carrying media to the event; the next checks should focus on health warnings and whether the event has been published.
Read the stream-health message literally and note when it appeared. YouTube distinguishes critical errors, which can prevent a stream from starting or cause viewer problems, from moderate warnings that may affect quality. A warning about a codec calls for a codec check, not a new stream key. A bitrate or network warning calls for a different investigation than a message about resolution or keyframes. Let the displayed error select the next check.
For encoding guidance, use YouTube’s live encoder settings and match recommendations to the resolution, frame rate and codec you have actually selected. Its general RTMP/RTMPS guidance lists H.264, H.265/HEVC or AV1 video and AAC or MP3 audio, with constant bitrate encoding. It recommends keyframes every two seconds and says they should not exceed four seconds. These are settings to verify against the applicable mode and error message, not a reason to change a healthy configuration without evidence.
Check the message’s named issue against the corresponding encoder setting:
| Health clue | What to inspect first |
|---|---|
| Format or codec warning | Video codec and profile, audio codec, and container or output mode |
| Bitrate warning or unstable quality | Selected bitrate against YouTube’s recommendation for that codec and resolution, and available upload capacity |
| Keyframe warning | GOP or keyframe interval in the encoder |
| Audio or video stream warning | Whether the expected audio and video tracks are enabled and configured as required |
| Resolution warning | Output resolution and the ingestion mode selected for the event |
| Primary/backup mismatch | Matching resolution, codecs, frame rate, bitrate and keyframe frequency across both feeds |
Do not infer a suitable bitrate from an unrelated resolution or codec. If YouTube says the connection cannot sustain the chosen resolution, lowering resolution may be more sensible than repeatedly restarting at the same demand. Change one relevant setting at a time, then observe whether the message clears and whether preview remains stable.
Confirm the scheduled event’s go-live steps
If YouTube shows an incoming preview, check the event’s own state and controls. For a scheduled stream, YouTube’s encoder workflow may ask you to wait for the preview and then select Go live in Live Control Room. In that configuration, a connected encoder can be sending media while the event is still awaiting the host’s action. Confirm the button and event state shown on your screen rather than expecting the encoder indicator to publish the event automatically.
This is not a single workflow for every configuration. YouTube’s stream settings include auto-start and auto-stop options; with auto-start enabled, starting the encoder can control the transition into a live state. Look at the settings for this particular stream and determine whether you intended a manual go-live step or an automatic transition. A scheduled event can also have controls or timing that differ from a test stream, so verify the actual event rather than assuming settings carry over.
If manual go-live is expected, wait until the incoming preview is present and use the event’s Go live control when it is available. If auto-start is enabled, check whether the expected transition has occurred and whether a health warning is blocking it. Avoid pressing controls on a different event simply because its title looks similar; first confirm the event identity and audience visibility you intend.
For a recurring channel, write down the intended pattern: scheduled event or ongoing event, manual publication or auto-start, and which encoder profile feeds it. That small handover note is useful if somebody else starts the stream overnight. It also makes a test easier to interpret, because you can tell whether the failure is a missing feed or an uncompleted publication step.
Check auto-start behaviour
Auto-start is a setting to verify, not a blanket remedy. If it is on, encoder activity may be the trigger for YouTube to start the event; if it is off, a person may need to publish the event from Live Control Room. Check the current setting for the selected event and compare it with the workflow you expect. Do not toggle it during a live attempt without considering what that would do to the event’s state.
Auto-stop can affect what happens when the encoder disconnects, so include it in the review if the event starts and then ends unexpectedly. These controls are distinct from stream health: a healthy incoming preview says something about the feed, while auto-start and auto-stop govern transitions in the event workflow. YouTube documents these options in its live stream settings help; follow the controls and wording shown in your own Studio interface, as settings and workflows can vary.
If your channel uses a repeatable unattended schedule, test the chosen settings in a private or otherwise appropriate test event before relying on the routine. Confirm who or what is expected to trigger publication and what you should see in Live Control Room afterward. A written checklist should state the actual workflow, rather than a general rule such as “starting the encoder makes the stream live”.
Review encoder output and ingest status
Once event selection and publication controls have been checked, review the encoder itself. Confirm that its preview and, if available, a local recording show the expected picture and sound. Check for encoder errors, excessive CPU load, or an output mode that differs from the one you believe you selected. A clean local output does not prove YouTube has received it, but it helps separate an encoding problem from a destination or event-state problem.
Then assess the outbound connection. Compare the combined stream bitrate with a current upload test and leave headroom; YouTube recommends 20% upload-bandwidth headroom. A connection that barely matches the nominal bitrate can still falter when other devices use the network or conditions vary. If upload capacity is insufficient or unstable, reduce the stream’s demand, test on a more reliable connection, or speak with your internet provider as appropriate.
Use the health message to decide whether to revisit codec, bitrate, frame rate, resolution, audio configuration or keyframe interval. YouTube’s general guidance supports frame rates up to 60 fps, but that does not mean every resolution and codec combination should use the same settings. Choose settings for the selected mode and what your connection and encoder can sustain. If using primary and backup ingestion, verify that the two outputs match in the settings YouTube identifies for failover.
Treat RTMPS connection errors as a separate branch. If the message points to SSL, certificate or timeout trouble, confirm that the encoder is set to the RTMPS URL shown in Live Control Room and that it supports that protocol. YouTube suggests trying port 443 for relevant SSL or timeout errors when the encoder permits a port to be specified. Do not switch protocols just because a stream has not been published if the preview and health state point instead to an event-control step.
Keep the encoder version and its logs if the problem persists. Note whether you use RTMP or RTMPS, but never include the stream key in shared evidence. The local preview, recording, CPU behaviour and upload test result help support staff narrow down which part of the path needs attention.
Retry after correcting the identified issue
Make a retry useful by changing the setting that matches the evidence. If the event was wrong, select the intended event and its current credentials. If the health panel identified a keyframe or format problem, correct that encoder setting. If the preview is healthy but the event awaits publication, follow the workflow configured for that event. Restarting without addressing the indicated issue may simply reproduce the same state.
Before reconnecting, confirm the event remains the one you mean to use and that the URL and key still correspond to it. If you changed a key, update the saved encoder profile too. Start the feed and watch Live Control Room for the incoming preview and health status; then follow the event’s manual or automatic go-live behaviour as configured. Check the event from a viewer’s perspective after publication, using the intended visibility and audience context.
If you run a continuous devotional, ambience or study channel, this distinction matters during overnight recovery. A restart can restore an encoder connection but still leave the event waiting for a manual action, or feed a different event than the one viewers expect. Keep a short recovery checklist beside the operator instructions. For a broader look at service choices and operating trade-offs, see our comparison of 24/7 YouTube streaming services. If your workflow involves prerecorded material and limited access to a dedicated computer, our guide to streaming from a Chromebook through remote desktop covers a different operational constraint.
When reporting a persistent fault, include the exact timestamped health text, event type and settings, encoder name and version, relevant logs, and what you saw in preview or a local recording. Add the upload test result and CPU observations if they are relevant. Do not share a live stream key. YouTube’s troubleshooting guidance advises reporting continuing issues; the evidence above makes the report more actionable than “it says streaming but is not live”.
If your goal is a long-running prerecorded channel, decide whether operating an encoder continuously is the right fit for your situation. A guide to building a 24/7 exam revision stream discusses planning that kind of channel, while setting up a 24/7 radio livestream from Kerala covers a different always-on use case. These are planning references, not substitutes for checking the specific event state and health message when a stream fails to publish.
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
OBS says it is streaming, but YouTube says waiting for data. What should I check?
Open the intended event in Live Control Room and compare its URL and current stream key with the encoder settings. If no preview arrives, use the exact health error to guide checks of destination, protocol, and encoding. Do not treat OBS’s indicator as proof that YouTube is receiving the intended event.
The preview is visible. Why can’t viewers watch yet?
A visible preview means YouTube is receiving a feed, but the event may still need to be published. Check whether this event expects you to select Go live, or whether auto-start is enabled, and inspect the event’s current state. Follow the workflow configured for that event rather than assuming a universal sequence.
Should I reset the stream key or lower the bitrate first?
Neither is a universal first move. Reset or replace a key when it is stale, reset, or implicated by the connection error; update the encoder with the current key. Lower bitrate or resolution when the health message or upload capacity indicates the feed cannot be sustained, and change the relevant setting rather than guessing.
What information should I send if the stream still will not go live?
Keep the exact error text and timestamp, encoder version and logs, event settings, whether preview appears, and any local recording, CPU or upload-test observations that help explain the fault. State whether you use RTMP or RTMPS, but never include the stream key. Check YouTube’s current official troubleshooting page for the reporting route.