For YouTube live stream outage alerts, build a two-layer health check: supervise FFmpeg locally, then check what YouTube reports about the incoming stream. This catches different failures and gives you better evidence than a single “stream down” notification.
FFmpeg can be running while YouTube reports an unhealthy or inactive feed. Conversely, a stopped encoder is a local failure even before YouTube’s status reflects it. Neither signal alone proves what every viewer can play, so the aim is to identify the failing layer and act on it.
Why process health and stream health differ
A process check answers a narrow question: is the FFmpeg program still running? A progress check adds evidence that it is continuing to process media. Neither confirms that YouTube is receiving the expected video and audio or that its ingestion checks are healthy.
YouTube’s liveStream resource documentation exposes status.streamStatus and status.healthStatus for the feed sent to YouTube. The active stream status means YouTube is receiving data; it does not mean every viewer can play the stream without a problem. Health status and configuration issues provide a separate receive-side signal.
For example, an FFmpeg process might keep running while its input has stopped changing, its output is misconfigured, or YouTube reports an ingestion problem. The process can also exit after an input or network fault while YouTube’s displayed state takes time to update. Treat these as separate observations, not competing verdicts.
This distinction matters for a 24/7 channel. If a devotional loop, study session or local news slate is meant to run overnight, a green process indicator can give false reassurance unless you also look at progress and YouTube’s view of the feed. A practical guide to reconnecting a 24/7 stream on a VPS addresses recovery; a watchdog first helps you tell whether recovery is needed and where to look.
A two-layer watchdog therefore gathers local evidence and YouTube-side evidence. It reports them independently, with timestamps, so you can distinguish “encoder stopped” from “YouTube received data but reports a health issue”. If audience playback itself is your concern, that is another check: the receive-side API status is not a substitute for testing playback.
Emit and monitor FFmpeg progress
FFmpeg’s -progress option emits program-friendly progress information to a URL. For a simple supervised command, send it to standard output with -progress pipe:1, and ensure the supervisor reads that output instead of allowing it to fill an unread pipe. The FFmpeg command-line documentation describes progress records as key=value lines ending with a progress key whose value is continue or end.
A simplified command shape might look like this:
ffmpeg -re -i input.mp4 \
-progress pipe:1 \
-f flv "rtmp://a.youtube.com/live2/STREAM_KEY"
Use your actual input, output settings and YouTube ingest destination. Treat the stream key as a secret: do not put it in a public script, shared log or alert message. This is a command shape to illustrate where the progress option sits, not a complete production configuration. The FFmpeg bitrate and resolution guide can help with the media settings, while this article focuses on noticing faults.
The monitor should read complete progress blocks and record the time each block arrives. It can also retain selected fields, such as the latest frame or media time, to help identify whether output is moving. Avoid treating every individual line as a fresh health event; the block-ending progress line gives a useful boundary for a complete update.
FFmpeg’s -stats_period controls how often it updates encoding progress and statistics. The documentation lists a default of 0.5 seconds, but that is an FFmpeg setting, not a recommended outage threshold. You can choose a different reporting period if your command and monitoring design call for it. Do not confuse frequent local updates with proof that YouTube is healthy.
If you use a service manager or a small wrapper script, have it supervise both the FFmpeg process and the progress reader. The reader needs a clear failure path: if the process ends, record its exit status and time; if progress stops arriving while the process remains present, record that as a different condition. A local log is helpful, but an alert destination must be configured separately if you expect someone to hear about a failure.
For a multi-stream setup, identify each process and YouTube broadcast clearly. A progress message for the wrong channel is worse than no message because it can send you to the wrong recovery steps. If you share a config across channels, label each stream at the point where the watchdog records and alerts; the pattern in one FFmpeg config for multiple YouTube streams is relevant to keeping those identities organised.
Detect process exit or stale progress
Track process state separately from progress freshness. A process-exit event means FFmpeg is no longer running, and its exit code and stop time are useful evidence. A stale-progress event means the process may still exist but the supervisor has not received a complete progress block recently. These conditions suggest different first checks: process exit points towards logs and restart policy; stale progress calls for checking the process, input and output path before assuming it is dead.
There is no universal stale interval prescribed by FFmpeg or YouTube. Choose one based on the progress cadence you configured, the input type, the expected processing behaviour and what delays are normal on your host. A file loop, a capture input and a complex filter chain may not behave identically. Start by observing a healthy run, then set a threshold that leaves room for normal variation without making a long silence indistinguishable from normal operation.
Record the last complete progress time, not only the most recent line written to a log. If a record is incomplete, it does not establish that the expected update arrived. The monitor should also distinguish a planned stop from a failure: during maintenance, a deliberate shutdown should not generate the same urgent alert as an unexpected exit in the middle of a scheduled broadcast.
A minimal local state model can include the expected broadcast window, FFmpeg process state, last progress timestamp and last exit status. If the channel is intentionally offline at certain hours, the monitor needs that context or it will alert on expected inactivity. Keep the rule understandable enough that you can inspect it during an overnight interruption rather than having to reverse-engineer a complex health score.
If FFmpeg exits, an automatic restart may be appropriate for a known transient failure, but do not restart blindly in a loop without recording attempts and outcomes. If it remains alive but progress is stale, gather evidence before restarting: check the process output, input availability and YouTube-side state. A restart can restore a stuck encoder, but it can also erase clues or interrupt a feed whose real issue is elsewhere.
Finally, consider where the watchdog itself runs. A monitor on the encoder host can detect a local process exit, but it may be unable to send an alert if that host, its power or its internet connection fails. A separately hosted monitor can observe some failures from outside that failure domain, at the cost of extra setup and another dependency. Decide which failures matter enough to justify that separation.
Check YouTube stream status and health
For automated receive-side checks, use the YouTube Live Streaming API resource for the stream associated with your broadcast. Inspect liveStream.status.streamStatus and liveStream.status.healthStatus; make sure you are checking the resource that corresponds to the channel and stream key in use. API access, authorisation, quota and polling details depend on your implementation, so verify the current YouTube API reference rather than assuming a copied script will work unchanged.
Documented stream status values include active, created, ready, inactive and error. In broad terms, active indicates YouTube is receiving data, while the other states describe a stream that is not in that receiving state or has an error. Interpret the status in relation to whether you expect the broadcast to be live: ready may be normal before starting, but unexpected during a scheduled 24/7 broadcast.
The health status values include good, ok, bad and noData. The API describes noData as meaning the live-streaming backend has no health-status information. That is not the same thing as a confirmed failed stream. Repeat the check and compare it with FFmpeg progress and the expected broadcast state before deciding what it means; do not automatically restart solely because of one noData observation.
Health details can include an update time and configuration issues. Preserve the issue reason and description that YouTube returns, along with the time of the observation. Examples in YouTube’s issue documentation include no audio or video, an unsupported video codec, mismatched primary and backup stream settings, and video ingestion starvation. The exact issue matters: a generic alert does not tell you whether to inspect media output, settings or the feed itself.
Health labels also need careful reading. YouTube documents good as having no configuration issues at warning severity or worse, while ok means there are no issues at error severity. Therefore, ok is not the same as saying there are no issues at all. Your monitor should preserve the returned state and issue list rather than flattening every non-bad observation into “all clear”.
API polling is useful when you have implemented API access and want an automated receive-side signal. The documentation does not prescribe one universal polling cadence or notification method. Choose a cadence that is useful for your operation and appropriate to your API use, and avoid presenting your chosen interval as an official YouTube requirement. The monitor should retain the observation time because status can change between checks.
Use Live Control Room as a manual check
You do not have to build API polling to use YouTube’s receive-side diagnostics. Live Control Room shows stream health and error messages, which makes it useful when you are operating a channel yourself or investigating an alert. YouTube Help’s live stream metrics guidance explains how to check health and analytics while streaming.
The Health Indicator can show specific error messages with timestamps and instructions. When an alert arrives, compare its timestamp with the message in Live Control Room and note whether the message is current or has cleared. This turns a vague “YouTube unhealthy” alert into a concrete troubleshooting step, such as checking that audio and video are present or reviewing a reported codec issue.
Manual review is a sensible starting point for a channel that has an operator available during broadcasts. It is not an automated overnight watchdog: someone has to open the dashboard and notice a change. If the stream runs when nobody is watching, API checks or another monitoring arrangement are needed to raise the signal outside the dashboard.
Keep the distinction clear in your runbook. The dashboard is an alternative way for a person to inspect YouTube’s side, while local FFmpeg supervision still detects process exit and stale progress. It is not a replacement for checking whether the encoder is alive, and an API check is not a replacement for interpreting a detailed message when one is available.
Define alert conditions and useful context
Start with separate alert rules, then decide which deserve immediate attention. A reasonable design might alert on an unexpected FFmpeg exit, progress that has gone stale beyond your chosen interval, or a YouTube status or health condition that is unexpected for the broadcast state. Those are implementation choices based on documented signals, not thresholds or a delivery guarantee prescribed by YouTube or FFmpeg.
| Signal | What it tells you | Useful first check |
|---|---|---|
| FFmpeg exited | The local encoder process stopped | Review exit time, status and recent process log |
| Progress is stale | No complete progress block has arrived as expected | Check the process, input and progress reader |
| YouTube reports unexpected stream status | The receive-side state differs from the planned broadcast | Confirm the correct stream resource and current broadcast state |
YouTube health is bad or has issues |
YouTube has reported receive-side health concerns | Read the issue reason, description and timestamp |
Health is noData |
YouTube has no health-status information for that observation | Repeat the check and compare other signals |
Every alert should include the channel or stream label, observation timestamp and failed check. Include the last progress time for local alerts, and the latest YouTube state plus issue reason and description when available. Add a short pointer to the relevant log or dashboard, but never include a stream key, access token or other secret. If multiple broadcasts share one alert destination, identification prevents an operator from restarting the wrong one.
Consider deduplication or a short confirmation window if brief transient observations would otherwise produce repeated notifications. Make the rule visible in your runbook: how many observations or what elapsed period triggers an alert is your choice, not a universal platform threshold. A confirmation window can reduce noise, but it also delays notification, so set it in light of how quickly someone needs to respond.
You should also decide how alerts clear. A recovery message can say which signal returned to its expected condition and when, rather than simply announcing “back up”. Keep the failure and recovery events paired in logs so you can see whether a restart fixed the local process, whether YouTube’s state changed afterwards, or whether the receive-side issue remained.
Do not infer audience playback from active alone. If viewers report buffering or a blank picture while the encoder and receive-side checks look normal, investigate playback separately. The YouTube stream disconnect troubleshooting guide covers a different class of interruption and can help frame host-side checks, but your own evidence should determine the next step.
For a channel run by one person, the alert can be concise but still actionable: “Bhajan loop: FFmpeg running, progress stale since [time]; YouTube health [state], latest issue [reason]. Check encoder log and Live Control Room.” That gives the operator a location and a distinction to investigate, rather than asking them to guess what “outage” means.
Test the watchdog and alert path
Test the monitor before relying on it during an unattended broadcast. First run a normal stream and confirm the supervisor sees FFmpeg start, receives complete progress blocks and records their arrival times. Verify that the YouTube check is looking at the intended stream and that its status observations make sense before, during and after the planned broadcast state.
Then test the failure paths in a controlled setting. You can stop a test FFmpeg process and check that the process-exit event is recorded. You can also validate stale-progress detection by using a safe test setup that stops or withholds progress output without disrupting a public broadcast. The point is to confirm that each rule fires for its own condition, not to create an avoidable outage on your live channel.
Send a test notification through the actual destination you intend to use, and check that it reaches the right person or team with the expected identifying details. A watchdog that writes a perfect log but has no working notification route will not alert an operator. Verify that secrets are absent from notification content and that the person receiving the message can open the relevant log or dashboard.
YouTube advises testing with audio and movement similar to the actual event and monitoring stream health and messages during the event. For a looped video channel, test the real media path, including audio if your published stream contains it, rather than assuming a static slate exercises the same conditions. Check Live Control Room during the test and compare its messages with the monitor’s recorded timestamps.
Finally, document normal states and the first response for each alert. Include who is expected to respond, where to find FFmpeg output, how to inspect the correct YouTube stream, and what counts as a planned stop. Revisit the test after changing the input, command, stream key, API access or notification destination; a watchdog is only useful if its assumptions still match the way you operate.
If maintaining an FFmpeg host and a separate monitoring path is more than you want to operate, StreamNeo removes the need to keep your own computer running for a file-based 24/7 YouTube broadcast, while you still need to check the channel and platform as appropriate.
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 an FFmpeg process that is still running mean the YouTube stream is healthy?
No. Process state and progress are local signals; YouTube separately reports the incoming stream’s status and health. Compare both layers, and remember that even active does not establish that every viewer can play the broadcast without problems.
What stale-progress timeout should I use?
There is no universal timeout in the FFmpeg or YouTube guidance described here. Choose one based on your configured progress cadence and normal behaviour for your input and host, then validate it during a healthy run and a controlled test.
Is noData the same as a stream outage?
No. It means YouTube has no health-status information for that observation, not that a failure is confirmed. Repeat the check and compare it with FFmpeg progress, process state and the expected broadcast state before taking action.
Can Live Control Room replace an automated watchdog?
It can provide a useful manual view of YouTube’s health indicator and error messages, but a person must check it. If you need an alert while nobody is watching, configure an automated monitor and notification path, and test that the alert reaches its intended recipient.