Azure Monitor cannot see your YouTube live stream on its own. To alert when it stops, a separate monitor must collect a YouTube signal and send it to Azure Monitor, where you define what should trigger an alert.
Keep three problems separate: YouTube is no longer receiving stream data, YouTube reports a stream or configuration error, or the monitoring process has stopped reporting. An alert for one does not necessarily catch the others, and none guarantees uninterrupted streaming.
What Azure Monitor can and cannot observe
Azure Monitor evaluates data that reaches it; it does not inspect a YouTube broadcast or verify what viewers see. The connection described here is a reference design assembled from YouTube’s API fields and Azure’s ingestion and alerting features. The official documentation reviewed does not provide a ready-made YouTube-to-Azure connector.
That distinction matters when an alert does not arrive. The original problem might be a stream failure, but a broken poller, expired credentials, a network problem or failed ingestion could prevent Azure from receiving evidence of it. Your design should therefore monitor both the YouTube status and the freshness of the monitoring data.
Treat API status as evidence about the input or broadcast state, not a complete viewer-side test. A stream can have a reported input state while some other playback, content or presentation problem still needs a separate check. Decide what you need to know: whether YouTube is receiving encoder data, whether the scheduled broadcast is live, or whether viewers can play the intended content.
A practical design has four stages: poll the appropriate YouTube resource, record a timestamped observation, ingest that record into Azure Monitor, and evaluate it with an alert rule. An action group then handles notification or a configured automated action. Each stage can fail independently, so test the full path rather than assuming that creating a rule completes the setup.
If you operate the channel from a local machine, the collector has to run somewhere reliably and reach both the API and Azure. The operational trade-off is between maintaining that monitoring process yourself and using a service that removes a computer-running burden. StreamNeo addresses the latter for a different part of the problem: it runs an uploaded video as a YouTube live stream without requiring your computer to stay on, so the channel is not dependent on that computer continuing to broadcast. It does not replace the separate Azure monitoring design described here.
Choose the YouTube stream signal to collect
Start by writing down what event should wake someone. For loss of incoming encoder data, inspect the liveStream resource’s status.streamStatus. YouTube defines inactive as not receiving data via the stream. A value of active means YouTube is receiving data; it does not prove every viewer can watch successfully.
The documented stream status values include active, created, error, inactive and ready. In your rule, decide which values need an immediate page and which deserve investigation without waking someone at night. For example, an inactive stream that is expected to be running may warrant a page, while a ready stream may be normal before the broadcast starts. The expected state depends on how your channel is operated.
Collect status.healthStatus as a separate diagnostic signal. Its status can be good, ok, bad or noData, and its details can include an update time and configuration issues with severities such as info, warning and error. YouTube documents error severity as meaning the video cannot be broadcast to viewers. A health warning can help you intervene early, but it is not interchangeable with a report that incoming data has stopped.
The broadcast resource has a different purpose. A liveBroadcast resource’s status.lifeCycleStatus describes the event lifecycle, such as a broadcast being upcoming, live or complete. It is not the same as the input state of the liveStream resource. Confirm which broadcast and stream IDs are connected in your setup before alerting on either resource; an always-on channel may handle events differently from one continuous input.
For reliable interpretation, include enough context in each record to identify the channel, stream and, where relevant, broadcast. Store the observed stream status, health status, health update time and observation timestamp. Avoid putting a stream key or other secret in the log record. The record is an operator-designed schema, not a structure mandated by YouTube or Microsoft.
| Signal | What it tells you | Useful alert condition | What it does not establish |
|---|---|---|---|
streamStatus |
YouTube’s reported incoming stream state | Expected-to-run input is inactive or error |
That every viewer can play the stream |
healthStatus |
YouTube’s stream health and configuration diagnosis | A relevant issue or severity appears | That input has stopped in every case |
lifeCycleStatus |
The broadcast event’s lifecycle | An event is not in its expected lifecycle state | Whether encoder data is arriving |
| Monitor heartbeat | Whether your collector has reported recently | No observation has arrived within your chosen tolerance | That YouTube itself has failed |
Poll the relevant Live Streaming API resource
The collector must request the resource associated with the signal you chose. For incoming data, poll the YouTube Live Streaming API’s liveStream resource and read status.streamStatus and status.healthStatus. If the event lifecycle matters as well, retrieve the associated liveBroadcast state separately. The YouTube LiveStreams resource documentation describes the stream fields; the LiveBroadcasts resource documentation documents the separate broadcast lifecycle.
Use the channel’s actual resource IDs rather than assuming a broadcast ID and stream ID are interchangeable. Check API access and the channel’s YouTube live-streaming setup before relying on a collector in production. The article’s design does not imply a particular polling rate: API quota, operating tolerance and the risk of delayed detection all affect that choice. Confirm current API requirements and quota guidance with Google’s official documentation.
Each poll should result in a timestamped observation, including when the request fails. If failures simply produce no record, a downstream rule may be unable to distinguish an API problem from a quiet interval. You can record a failed poll as its own outcome and keep the time of the last successful observation, so operators can see whether the collector reached YouTube and what it returned.
For a channel that runs from OBS or FFmpeg, API status is a useful complement to encoder-side checks, not necessarily a replacement. A local check can tell you about output bitrate or dropped frames; YouTube’s resource reports what YouTube says about the input. For that separate layer, see this guide to checking FFmpeg bitrate and dropped frames. If you are still choosing how to keep the channel running overnight, the low-cost VPS guide for OBS in India covers a different operational choice from cloud-side status collection.
Make the signal available to Azure Monitor
One documented route is to send JSON observations to a custom Log Analytics table using the Azure Monitor Logs Ingestion API and a data collection rule (DCR). The collector makes a REST request or uses a client library; the DCR defines the expected input and routes the data to the table, with optional transformation. Microsoft’s Logs Ingestion API documentation explains the ingestion path and its prerequisites.
A typical record might include an observation time, channel or broadcast identifier, stream ID, streamStatus, health status, health update time, poll outcome and a monitor heartbeat. Use consistent field types and timestamps so a query can distinguish the latest observation from older ones. The DCR input structure must match what the collector sends; check a real ingested record before writing alert queries against the table.
The API requires an application registration with access to the DCR. Protect its credentials and grant only the access needed to send the data. Keep secrets out of records and alert payloads, and document how credentials will be rotated. The collector also needs a place to run and a recovery plan if its process exits. This is a meaningful amount of setup: the design gives you control over the signal and query logic, but it makes API access, identity and ingestion your responsibility.
Another possible design is to publish a custom metric heartbeat and use metric alerts. That may suit a narrow question such as whether a collector is still reporting, while Log Analytics records are useful when you need to query status transitions and diagnostic fields together. Neither path removes the need to build and operate the collector. Compare current Azure pricing for your region, signal volume and evaluation pattern before choosing; costs depend on the chosen alert and ingestion configuration, and this article does not prescribe a price or cadence.
Create alerts for distinct failure modes
Use separate conditions, even if they ultimately notify the same person. A log search alert can run a Kusto Query Language (KQL) query over the observations. One rule can look for an unexpected inactive or error state; another can detect a relevant health issue; a third can detect that observations have gone stale. Microsoft describes scheduled query rules and their alert configuration in its documentation.
For the input rule, define when the stream is expected to be active and what counts as an unhealthy state for your channel. Do not page merely because a stream is ready before its scheduled start, unless that is genuinely abnormal in your setup. For the health rule, choose whether warnings should be informational or actionable; an error that prevents broadcast may justify a different response from a warning that calls for a configuration review.
The stale-observation rule is essential because an explicit-state rule cannot fire on a status it never receives. Query the latest observation time for the relevant stream or collector, then alert when that time is older than your chosen tolerance. This can signal a stopped poller, unavailable credentials, a network failure or an ingestion issue; it does not by itself prove that YouTube is down. Include the last successful poll time if you can, to help narrow down which link failed.
Choose the tolerance from the operating need, not from an assumed universal interval. Detection has several stages: time until the next poll, API response and ingestion delay, alert evaluation schedule, then action delivery. A fast poll paired with a slow alert evaluation can still produce a delayed notification. Conversely, aggressive polling and frequent evaluation may increase load or cost. Azure documents alert evaluation and pricing considerations, but there is no end-to-end detection time established here for your channel.
Attach an Azure Monitor action group to each rule. An action group can notify people or invoke an Azure Function, Logic App or webhook. Microsoft’s action groups documentation describes supported actions and delivery considerations. For an automated endpoint, make sure it can authenticate and handle the payload schema; Microsoft recommends the common alert schema for a consistent set of fields across supported alert types. A Logic App may be useful when the receiving system expects a different structure.
Treat notification as a delivery path that needs its own checks. Microsoft documents retry behaviour for failed webhook calls, followed by a period in which the action group does not call an endpoint after retries fail. A receiving service can also be unavailable or misconfigured. Monitor the endpoint, test the payload and avoid making a single webhook the only way an operator can learn of a critical problem.
Test alert delivery and monitoring health
Test each failure mode deliberately before relying on the rule overnight. Send a known observation representing an unhealthy input state and confirm that the query returns the intended row, the alert rule fires and the action group reaches its recipient. Then test a stale observation separately; an explicit inactive test does not show that the no-data rule works. Use a non-production stream or controlled test data where possible, so a test does not disrupt the live channel.
Check the entire chain: API permission, collector execution, record shape, DCR routing, table arrival, query result, alert evaluation and notification. If a record arrives but the query misses it, inspect time zones, field names, null values and the distinction between event time and ingestion time. If the query finds it but no alert arrives, inspect rule state, dimensions, action group configuration and the receiving endpoint. Keep a short runbook that identifies where to look first.
Test recovery as carefully as detection. After the signal returns to a healthy state, determine whether the alert resolves, whether a recovery notification is useful, and whether repeated observations cause duplicate pages. A rule that pages correctly but remains stuck in an active state can create confusion on the next incident. Set suppression or grouping only when it preserves the context operators need.
Finally, arrange for the monitor to report its own condition. A heartbeat can show that the collector ran recently, while a recorded poll outcome can show whether it reached YouTube. Alert on stale heartbeat independently from an unhealthy stream state. This is particularly important for unattended channels: an empty dashboard may mean a healthy quiet stream, a failed poller or an ingestion gap unless you preserve freshness information.
If the channel’s YouTube access changes hands, verify that the collector still has the intended access and that the correct channel resources are being queried. The guide to YouTube Live access after changing the channel owner is relevant when permissions shift. For a separate question about what happens after a broadcast ends, see whether a new livestream can start immediately; broadcast lifecycle and input status should not be conflated in the alert design.
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 Azure Monitor automatically know when my YouTube stream stops?
No. You need a process to collect a signal from YouTube and send it to Azure Monitor. An alert can only evaluate the data that reaches its rule, so the collector and ingestion path need monitoring as well.
Which status should trigger the main outage alert?
For loss of incoming data, start with liveStream.status.streamStatus and decide how to treat an unexpected inactive or error state. Use healthStatus for configuration and health diagnostics, and liveBroadcast.status.lifeCycleStatus when the event lifecycle is what matters. These fields answer different questions.
Can an Azure alert guarantee that the stream stays live?
No. It reports a condition after collection, ingestion, evaluation and delivery, and any part of that chain can be delayed or fail. Use the alert to prompt an operator or configured action, and test the full recovery process rather than treating notification as prevention.
What if no status record arrives?
Treat missing telemetry as its own condition. Alert when the latest observation or heartbeat is older than a tolerance you chose for your channel, then investigate the collector, credentials, network and ingestion path before concluding that YouTube itself stopped receiving data.