First check whether the Docker container exited or is still running while YouTube reports the stream offline. A restart policy can restart a container that exits; it does not, by itself, repair a publishing failure inside a process that remains running.
Compare Docker’s state and timestamped logs with the stream-health messages in YouTube Live Control Room. That evidence can narrow the investigation, but the title alone cannot identify the cause.
First split: container exit or YouTube offline
A live stream can look offline for more than one reason. The encoder process may have stopped, taking its container with it. Or the container may still be up while its encoder has stopped publishing, lost its connection, or is sending a stream YouTube cannot ingest. Those situations call for different checks.
Start with the literal state Docker reports, not with a guess based on the YouTube player. Run docker ps -a to include stopped containers. Find the container that runs your encoder and note whether it is Up, exited, or repeatedly restarting. If it is stopped, its exit code and surrounding logs matter. If it is Up at the time YouTube is offline, a policy that only reacts to container exits may leave the problem untouched.
This distinction also helps if you are searching for “Docker container keeps restarting” or “YouTube stream goes offline”. A rising restart count points towards repeated exits; a stable running container shifts attention towards the publishing process, its settings, or the connection to YouTube. Neither observation proves the underlying fault. It tells you which evidence to collect next.
For a second view of whether a channel has actually returned to viewers, see how to check whether a 24/7 Indian music stream is actually live. The player’s state and the container’s state describe different parts of the path, so check both rather than treating either as a complete diagnosis.
Record Docker state and timestamps
Use inspection to capture the state, last exit code, restart count, and most recent start time together:
docker inspect -f 'status={{.State.Status}} exit={{.State.ExitCode}} restarts={{.RestartCount}} started={{.State.StartedAt}}' <container>
Replace <container> with the actual name or ID. If the container is running, the exit code may reflect a previous exit rather than a current error. Read it alongside the status and start time. A count that increases across checks is evidence that Docker has observed further restarts; a count alone does not explain why they happened.
Keep a short incident note with the time YouTube first showed offline, the inspection output, and the time zone used for your notes. This gives you a way to compare events without relying on memory. If you manage containers from a host with other scheduled work, note any planned restart, deployment, or maintenance at the same time. Correlation is useful, but does not by itself prove what caused the outage.
If docker ps -a shows the container has exited, investigate the process exit and startup path before changing policies. Look for a nonzero exit code, a repeated short run, a changed image or configuration, or a host or daemon event around the same time. If the container stays up, inspect whether the encoder itself is still active and reporting an error; container status cannot tell you whether YouTube is receiving valid video.
Read logs around the offline event
To check Docker container logs with timestamps, ask for a window around the reported outage:
docker logs --timestamps --since 30m <container>
The 30m window is an example of a command argument, not a recommended incident duration. Adjust it to include the period before and after the event. For ongoing observation, use:
docker logs --follow --timestamps <container>
Timestamped output can reveal whether the encoder reports a disconnect, retries, exits, or continues emitting its normal status messages. Look for the first meaningful change, not just the last line. A line appearing near the time the YouTube dashboard reports an error is a lead to investigate, not proof of causation.
Logs are useful only if your container’s logging setup makes them available through Docker. Docker notes that some logging drivers do not support reading output with docker logs; in that case, check the destination configured for the driver instead. Also protect credentials while sharing evidence: a stream key is credential-like, so do not post it in a public log excerpt or screenshot. You can redact keys and account-specific values before asking for help.
Check the log pattern alongside the restart count. If the container repeatedly exits and starts, compare each exit and startup with the offline timestamps. If the container remains up and its logs show repeated publishing or connection errors, investigate the encoder’s reconnect behaviour and connection rather than expecting Docker to restart it automatically. A quiet log is not proof that publishing is healthy; the application may not report every failure.
One further operational check is log growth and disk space. Docker’s default json-file logging driver does not rotate logs by default, while Docker documents local as a driver with rotation and compression. If your logs are unusually large or the host is short of disk space, treat that as a separate condition to investigate, not as an assumed explanation for this stream going offline. Review the Docker logging configuration documentation before changing a driver, and remember that changing defaults may not alter how existing containers were created.
Know what a restart policy does
Docker policies govern what happens when a container stops. They are not a substitute for an encoder’s own ability to detect a lost publishing connection and reconnect. Docker documents four policy choices: no (the default), on-failure, always, and unless-stopped. Their effects differ, so select one for the container lifecycle you actually want.
| Policy | What it does when the container exits | Useful distinction |
|---|---|---|
no |
Does not automatically restart it | Default behaviour |
on-failure |
Restarts after a nonzero exit | Does not restart just because the Docker daemon restarts |
always |
Restarts a stopped container, including after a daemon restart | Manual-stop behaviour differs from unless-stopped |
unless-stopped |
Restarts it unless an operator has manually stopped it | A manual stop remains in effect after a daemon restart |
Docker says restart-policy monitoring begins only after a container has run successfully for at least 10 seconds. This is relevant when a container fails immediately during startup: do not assume that setting a policy guarantees recovery from every short-lived startup failure. For exact current behaviour, use the Docker restart policy documentation.
For a long-running encoder container that should return after an exit or daemon restart, yet remain stopped after an operator deliberately stops it, unless-stopped may fit. For a Compose service, the setting looks like this:
services:
streamer:
image: your-encoder-image
restart: unless-stopped
For a container created with the CLI, the equivalent creation option is docker run --restart unless-stopped .... To update an existing container, Docker documents docker update --restart unless-stopped <container>. Use the actual image and arguments for your setup; the example is not a complete encoder configuration.
Do not combine Docker’s restart policy with a separate host-level process manager that tries to manage the same container without understanding how the two interact. Docker warns that multiple restart mechanisms can conflict. Most importantly, a more aggressive policy is not a fix for a publishing failure inside a process that is still running. If you need automatic recovery from a dropped YouTube connection, check whether the encoder has a documented reconnect option and investigate why publishing stopped.
Check YouTube Live Control Room health
Open the relevant broadcast in YouTube Live Control Room and inspect Stream health, including the messages and their timestamps. YouTube’s stream-health guidance describes errors associated with the incoming stream and distinguishes critical from moderate messages. Read the message itself rather than treating the player’s offline appearance as a diagnosis.
YouTube’s documented ingestion issues include incorrect bitrate, unsupported or incorrect codecs, audio or video stream structure, and keyframe frequency. If a health message appears while Docker remains up, use it to direct checks towards the encoder output and upload path. If the dashboard error and a Docker exit occur close together, investigate both. Similar timestamps can help you form a hypothesis, but do not establish that one event caused the other.
The two views answer different questions. Docker state and logs describe the container and what its process reports. Stream health describes how YouTube is receiving and assessing the incoming feed. A container can be running without a healthy incoming stream, and a dashboard message may point to a stream-format issue rather than a container lifecycle issue.
If the Control Room reports a stream-key problem, verify the configured key against the one shown for the intended broadcast and update it carefully. YouTube advises that a stream key should be treated like a password. Do not include it in a support request, public log, or screen recording. For broader channel setup, the Marathi devotional playlist live-stream guide is relevant to planning a continuous broadcast, but the current Control Room message should guide this incident’s diagnosis.
Review encoder and network behaviour
When the container is running but YouTube is not receiving a healthy stream, inspect the encoder’s output configuration and connection. YouTube’s live encoder settings list supported ingestion choices and recommendations, including RTMP or RTMPS, supported video and audio codecs, constant bitrate, and keyframe guidance. Settings depend on resolution, frame rate, and codec; consult YouTube’s current table for your combination rather than copying a bitrate from another channel.
YouTube recommends a two-second keyframe interval and says not to exceed four seconds. The recommendation is a setting to verify, not evidence that keyframe frequency is the fault in your case. Check the actual encoder configuration and compare it with the stream-health message. YouTube recommends RTMPS for encrypted ingestion; confirm that the encoder’s URL, key, and protocol correspond to the selected broadcast.
Then consider whether the upload connection can sustain the chosen quality. YouTube recommends selecting a quality level reliable for the available upload connection, testing before an event, and monitoring health during the broadcast. A stream that works briefly but becomes unstable under the actual conditions needs a practical test with the same sort of audio and motion as the real programme. Avoid increasing bitrate to “fix” a stream without evidence; more demand on a limited upload path can make reliability worse.
Check application-level reconnect behaviour separately from Docker policy. Some encoders can retry a publishing connection while remaining alive; others may stop output or require a restart. Consult the encoder’s own documentation and logs to learn what it does on connection loss. Do not infer that behaviour from a Docker restart setting. If the encoder is silent or stuck while its container remains up, a container policy may have no event to act on.
For VLC-specific symptoms on a connection such as Airtel broadband, the VLC buffering troubleshooting guide may help separate local playback or network symptoms from a Docker exit. Its relevance is in the network checks, not as a substitute for Control Room stream-health evidence.
Verify recovery at both ends
After changing a setting, verify more than a green container status. First check Docker: is the container stable, has the restart count stopped rising, and do timestamped logs show the encoder publishing rather than repeatedly retrying or exiting? Then check YouTube Live Control Room for healthy incoming-stream status and confirm that the broadcast is reaching the intended audience-facing player.
Use a controlled test before relying on a setup for a scheduled devotional programme, study channel, or overnight ambience stream. YouTube recommends testing in advance with conditions resembling the real event and monitoring stream health during the event. Confirm audio and moving video, not just a static preview. If you use an archive or local recording, verify that it is advancing as expected, while treating that as a separate observation from YouTube’s receipt of the stream.
If Docker is stable but YouTube remains offline, return to the encoder and ingestion evidence rather than escalating the restart policy. If the container exits again, collect the new exit code and log window before altering multiple settings. One change at a time makes it easier to see whether the evidence changed. For a continuous broadcast whose specific concern is having to keep a computer on and manually recover a file-based loop, StreamNeo removes that particular operating burden by running an uploaded video as a YouTube live stream with your computer off; it does not replace diagnosis of an encoder you operate in Docker.
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
Will restart: unless-stopped keep my YouTube stream online?
It can bring a container back after the container exits, subject to Docker’s documented behaviour and the container’s lifecycle. It does not repair a publishing failure inside a process that remains running. Check both Docker state and YouTube stream health before deciding what to change.
How do I check Docker container logs around an outage?
Use docker logs --timestamps --since 30m <container> to retrieve a recent window, adjusting the window to include the reported event. Use docker logs --follow --timestamps <container> to watch new output. Some logging-driver configurations do not make logs available through this command, so check the configured destination if output is missing.
What should I do if Docker says the container is up but YouTube says offline?
Inspect the encoder’s own logs and reconnect behaviour, then read the timestamped Stream health messages in Live Control Room. Check the configured stream URL and key privately, plus the codec, bitrate, audio/video structure, keyframe interval, and upload connection as relevant to the reported error. A running container alone does not show that YouTube is receiving a usable stream.
Does a rising restart count identify the cause?
No. It shows Docker has restarted the container, but the exit code and logs are needed to investigate why. Compare those timestamps with YouTube’s stream-health evidence, and treat a close match as a clue rather than proof of cause.