“Online” can mean that YouTube is receiving video, or that viewers can watch the expected live broadcast. These are separate states, so one green-looking signal is not enough to confirm both.
For a reliable check, identify the liveStream and its associated liveBroadcast, inspect the input stream’s status and health, then check the broadcast lifecycle. Treat each result as evidence about a particular part of the path, not as a blanket guarantee that everything is working.
Why “online” has more than one meaning
An automated stream has at least two relevant checkpoints. First, a feed is sent to YouTube. Second, a broadcast event is made available to viewers. YouTube represents these as distinct resources: a liveStream describes the video feed being transmitted, while a liveBroadcast represents the event streamed to YouTube. The LiveStreams API reference and LiveBroadcasts API reference document those separate roles.
That distinction matters in ordinary troubleshooting. If streamStatus is active, YouTube says it is receiving data via that stream. It does not, by itself, prove the associated broadcast is in the live lifecycle state, that the intended event is the one viewers can open, or that the video and audio are healthy. Conversely, a broadcast lifecycle result does not tell you every detail about the quality of its incoming feed.
It helps to name the question your check answers. “Is YouTube receiving this input?” is a stream question. “Is the event I intend people to watch live?” is a broadcast question. “Is the input reporting a delivery or configuration problem?” is a health question. Combining the answers can give you a useful operational picture; collapsing them into a single unqualified “online” flag hides the reason for a failure.
For a devotional channel, for instance, the automation may still be sending a loop while the public event has not reached the expected state. For a local news loop, the event might be live while a reported input issue needs attention. In either case, tell the operator which layer you have checked rather than reporting simply “stream is up”.
Identify the liveStream and liveBroadcast
Start with the resource pair for the event you care about. A broadcast has a bound stream ID when a stream is associated with it. Use that relationship to identify the corresponding liveStream; do not select a convenient stream merely because it is active. A channel can have multiple streams and broadcasts, including past or upcoming events, so resource identity is part of the check.
The broadcast resource documentation describes the broadcast’s bound stream relationship. The stream has its own ID and status fields, as set out in the stream resource documentation. In a monitoring record, keep the expected broadcast ID and bound stream ID together, along with the time the results were read. That makes it easier to notice when an operator is looking at the wrong event or an outdated association.
For API-based checks, listing broadcasts requires OAuth authorisation. The broadcasts list method supports filters including active, completed, upcoming, and all; it also supports mine=true to limit results to broadcasts owned by the authenticated user. The method requires exactly one of broadcastStatus, id, or mine. For a simple check of a known event, querying by ID can reduce ambiguity. For a channel overview, choose a suitable list filter and match the expected event deliberately.
Use an OAuth scope documented for the method, such as https://www.googleapis.com/auth/youtube.readonly when read-only access is sufficient. Keep the credential private and grant no broader access than the workflow needs. If the account is not enabled for live video, the API can return liveStreamingNotEnabled; that is an access or eligibility issue, not proof that an existing input has failed. If you rely on YouTube Studio rather than the API, confirm the event identity there too before interpreting its status.
A practical record might include the channel, expected broadcast ID, bound stream ID, last check time, and the separate results for stream status, health status, and broadcast lifecycle. Avoid storing a stream key in a monitoring log. It is a credential for sending video, not a field needed to explain whether the public event is live.
Check liveStream streamStatus
Read the stream’s status.streamStatus to answer whether YouTube reports receipt of input and what state the stream resource is in. The documented values are active, created, error, inactive, and ready. Interpret them according to YouTube’s definitions rather than treating them as a simple colour-coded uptime score.
streamStatus |
What the documented state tells you | Useful next check |
|---|---|---|
active |
YouTube is receiving data via the stream. | Read health status and check the associated broadcast lifecycle. |
inactive |
YouTube is not receiving data. | Check whether the sender is running and whether it is using the expected stream. |
ready |
The stream has valid CDN settings. | Do not infer that data is being received; inspect the broadcast and input state. |
created |
The stream has been created but lacks valid CDN settings. | Check stream configuration before expecting input to work. |
error |
An error condition exists. | Read available details and investigate the specific failure. |
The distinction between ready and active is particularly useful. A configured stream can be ready without currently receiving video. Likewise, active is evidence of receipt, not a synonym for a good-quality input or a public broadcast in the expected state. The official stream status definitions are the reference when a dashboard or monitoring script uses shortened labels.
If the result is inactive, check the sender before changing the broadcast. Is the encoder or automation process still running? Is it connected to the stream associated with this broadcast? Has its local network failed, or has the stream key or configuration changed? These are diagnostic questions, not conclusions supplied by the status value alone.
If the sender reports that it is connected but YouTube reports a different state, compare timestamps and resource IDs. A local process log describes what that process believes it is doing; the API field describes YouTube’s view of that stream resource. For a related set of input-side symptoms, see the guide to checking when OBS reconnects but stream health stays offline. It is useful when the sending application and YouTube appear to disagree, but it does not replace checking the broadcast lifecycle.
Review liveStream healthStatus
The stream’s status.healthStatus adds diagnostic context to the receipt state. Its documented values are good, ok, bad, and noData. YouTube defines good as having no configuration issue with warning severity or worse; ok as having no issue with error severity; bad as having one or more issues with error severity; and noData as meaning its live-streaming backend has no health-status information.
Do not read good as a guarantee that viewers see the right programme or that the broadcast is live. It is a statement about health information for the incoming stream. Similarly, noData is not the same as a known failure: it means the backend has no health-status information to report. Keep that uncertainty visible in your monitoring output instead of silently converting it to “healthy”.
The health object can include a timestamp for the most recent health update and descriptions of configuration issues. When available, review the issue type, severity, reason, and description. The documentation’s examples include low video bitrate, a frame-rate mismatch, and missing audio. These are reasons to inspect the sender’s settings and actual output; the field itself does not tell you that changing a particular setting will resolve every case.
If health is bad, report that an error-severity issue is present and capture the available issue details. If it is ok, report that no error-severity issue is reported, while retaining any lower-severity context that is available. If it is good, report the documented health condition, not an overall promise of flawless playback. If it is noData, report that health could not be assessed from this field and use the other signals and a direct viewing check as appropriate.
For repeated checks, preserve the health update timestamp. A newly read response may include health information whose last update is older than the time you queried it. Showing both times helps the person on call distinguish when the API was checked from when YouTube last updated the health assessment. Do not claim a particular detection delay: the references cited here do not establish one.
Check the associated broadcast lifecycle
Once you know the stream’s state and health, inspect the associated broadcast’s lifecycle. This answers the separate audience-facing question: what state is the event viewers are meant to watch in? Use the broadcast resource for that answer, and make sure it is the expected event rather than another broadcast belonging to the channel.
The broadcast lifecycle has documented states, including live and other states for events that are not currently live. Interpret the lifecycle field according to the broadcast API documentation; do not substitute streamStatus=active for this check. In a status message, say “input received; broadcast is live” only when both corresponding results support those separate statements. If input is active but the broadcast is not live, report exactly that mismatch.
The API’s transition method deserves particular care. It is a control operation that changes broadcast state, not a passive health-check endpoint. YouTube documents that the bound stream must be active before a broadcast can be transitioned to testing or live. Do not call a transition method simply to see whether the channel is working. A monitoring routine should read status; an authorised operator or carefully designed control workflow should make deliberate lifecycle changes.
If you manage the event in YouTube Studio, compare the public-facing event there as well when a result is ambiguous. A viewer-facing check can help verify that the intended event page is accessible and displaying the expected content, but it is not a substitute for the resource-level distinction. Keep the report precise: the stream status concerns incoming data, health concerns reported input issues, and lifecycle concerns the broadcast event.
Interpret mismatched states carefully
A mismatch is a prompt to investigate, not a reason to force both fields into the same label. The combination tells you where to look next, but does not always establish why the states differ. Record the observed values and their check times before restarting an encoder, changing a stream association, or attempting a broadcast transition.
| Input stream result | Broadcast lifecycle result | How to describe it and what to inspect |
|---|---|---|
active |
live |
YouTube reports input receipt and the expected broadcast is live. Review health and, if needed, confirm the viewer-facing programme. |
active |
Not live |
Input is arriving, but the event is not reported as live. Confirm the broadcast ID, its lifecycle, and whether the event is intended to be live now. |
Not active |
live |
The broadcast lifecycle says live, while the stream does not report active receipt. Check whether the stream association is correct and inspect the input path; do not infer from lifecycle alone that new video is arriving. |
Not active |
Not live |
Neither check confirms the expected live condition. Verify the event and stream IDs, sender state, and configuration before deciding what to restart. |
The table is a way to structure a report, not a complete diagnosis tree. For example, an active input paired with a non-live lifecycle does not tell you whether the event is waiting for an operator action, was selected incorrectly, or has another lifecycle issue. Use the API’s reported details and the channel’s intended schedule to decide what to do.
Also distinguish an absent or stale result from a known negative state. A failed API request, missing permission, unexpected resource ID, or unavailable health object is not equivalent to inactive or bad. Show an error or “not checked” state for the failed observation. This prevents a monitoring dashboard from giving false certainty when it has lost access to the evidence it needs.
For operators running a recurring recorded programme, a checklist can help separate content problems from delivery problems. The guide to running a YouTube Live VOD rerun channel covers the broader rerun setup; here, keep the monitoring question narrower: are the expected input resource and public event in their intended states? If audio gaps or a loop issue appear, investigate the media path as well as the resource states; the audio gaps troubleshooting guide addresses a different symptom that status fields alone may not explain.
Build a repeatable monitoring check
A useful routine reports evidence in a consistent order. First resolve the expected broadcast and its bound stream. Then read the stream status and health fields. Finally, read the broadcast lifecycle and report each observation with its resource identity and timestamp. That ordering makes it harder for an active input to be mistaken for a live public event.
For an API implementation, choose a polling approach that fits your operational needs, then verify its quota impact and behaviour against the current YouTube API documentation. The references cited here do not establish a universal interval, detection latency, or quota budget. Avoid copying a fixed cadence from an unrelated example and presenting it as a guarantee. Consider how quickly an operator needs to know, how often checks can reasonably run, and what the API quota permits for your project.
Make alerts actionable rather than noisy. A message such as “broadcast not live” lacks context if the event is scheduled to be offline. Include the expected event, observed lifecycle, stream status, health status, last health update if present, and the time of the check. Define which combinations need immediate attention for your channel: a devotional loop may have different operating hours and escalation needs from a local news channel.
Keep a manual fallback. If the API cannot be queried, check the relevant event in YouTube Studio and, where practical, view the public event. If the input is not active, inspect the automation or encoder and confirm it is targeting the bound stream. If input is active but the broadcast is not in the expected lifecycle state, investigate the event rather than blindly restarting the sender. This sequence can save you from making one component worse while trying to fix another.
Where your recurring pain is keeping a computer on just to feed a recorded programme, StreamNeo removes that specific local-machine dependency: you upload the video, connect the YouTube stream, and can leave your computer switched off while the stream is monitored and restarted if it drops. It remains important to check YouTube’s input and broadcast states separately; automation does not turn an active input into proof that the public event is live.
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 streamStatus=active mean my YouTube broadcast is live?
No. It means YouTube is receiving data via that liveStream. Check the associated liveBroadcast lifecycle separately to determine whether the event is in the expected live state.
What is the difference between ready and active?
ready means the stream has valid CDN settings, while active means YouTube is receiving data via the stream. A ready stream is not proof that a sender is currently delivering video.
What should I do if health status is noData?
Report that YouTube’s live-streaming backend has no health-status information for the stream. Check the stream and broadcast states, verify your resource IDs, and use the sender’s logs or a viewer-facing check as additional evidence rather than calling the input healthy.
Can I use the broadcast transition method as a monitoring check?
No. The transition method changes broadcast state; it is a control operation, not a passive read. Use resource reads for monitoring and make lifecycle changes only when they are intended.