If your 24/7 YouTube stream stops on an Oracle Cloud Always Free instance, first find out whether the VM stopped, the encoder process died, or the fault lies in the network, encoder settings or YouTube. Check the OCI Console and YouTube Live Control Room before restarting anything; the symptom alone does not identify the cause.
The checks below are diagnostic, not a report on your account or instance: neither has been tested. Work from the cloud VM towards YouTube, recording the time and exact message at each step. That makes it easier to distinguish a host or process failure from an ingest or playback problem.
Identify what stopped before changing settings
Start with two views: the OCI Console and YouTube Studio’s Live Control Room. In OCI, note the instance’s displayed state and any notification or error. In YouTube, check whether the event is still live, whether the incoming stream is healthy, and the time of any warning. Compare the times: if the VM stopped first, changing a stream key will not bring it back; if the VM is running but YouTube has no incoming video, the encoder or its route to YouTube deserves attention.
Use the terms shown in the Console rather than guessing. An instance may be running, stopped, disabled or terminated, or it may be unavailable for another reason. These states have different implications. Do not terminate or recreate the instance as a first troubleshooting step: check whether its boot volume and application files are preserved, and what the Console says about recovery, before taking an action that could discard data.
Also separate a creator-side interruption from a viewer’s playback report. If only one person cannot watch, ask them to try another connection or device. If viewers on one shared network report a problem, their network may be involved. Reports from several independent connections, together with a Live Control Room health warning, make the stream itself a more plausible place to investigate, but still do not prove which component failed. YouTube’s troubleshooting guide for live streams explains how stream health and viewer symptoms can help narrow the problem.
Keep a short incident note: time, OCI state, YouTube status, encoder log message, and any change made. Change one thing at a time. A chain of simultaneous restarts and setting edits can hide the original fault and make a temporary recovery difficult to repeat.
Check whether the Always Free VM is available
If the Console does not show the instance as running, investigate the cloud resource before the streaming software. Review tenancy notifications, limits and usage, along with any messages attached to the instance. Oracle’s Always Free cloud services page describes the available free allowances and notes that Always Free compute must be provisioned in the tenancy’s home region. Actual entitlement and capacity are tenancy-specific, so use the current Console and Oracle documentation rather than assuming a remembered allowance applies to your instance.
Oracle’s published idle-instance policy says resources may be reclaimed when, over a seven-day period, CPU utilisation at the 95th percentile, network utilisation, and, for A1 shapes, memory utilisation are each below 20%. This is a possible explanation to check, not a diagnosis of a stopped stream. A stream stopping by itself does not show that an instance was reclaimed; look for the actual state and any notice in your tenancy. Do not try to manufacture activity as a workaround. Artificial load is not a reliability plan and does not establish that a workload meets the policy.
If the VM is disabled, unavailable or terminated, read the specific notice and check whether the boot volume and data still exist before attempting recovery. Oracle also documents how trial expiry and Always Free entitlements are treated, but that general policy does not establish the status of a particular account. Check the current account state and applicable limits. Avoid assuming that upgrading an account will immediately solve an instance problem; it can affect access to resource types and charges, but it does not correct an encoder, key or YouTube issue.
An out-of-host-capacity message has a narrower meaning than “my stream stopped”: Oracle documents it in the context of creating a compute instance when an Always Free shape is temporarily unavailable. It does not by itself explain why a previously running instance or its process stopped. If you are actually trying to create an instance and see that error, Oracle suggests trying another availability domain where one is available, or waiting and retrying. Check the message you received rather than applying that advice to an unrelated failure.
If the VM runs, inspect the stream process
When OCI reports the VM as running, identify what launches the broadcast before issuing commands. It might be FFmpeg, OBS, a shell script, or a service managed by a supervisor. The service name and log location depend on how it was installed, so there is no safe universal restart command. If you did not configure it yourself, check the deployment notes or ask the person who set it up before changing service files.
Check whether the relevant process or service is active, then inspect its recent logs around the time the stream stopped. Look for an exit code, an input-file read error, an authentication or connection failure, a full disk, or a resource error. If the setup writes a local archive or output file, check whether that file was growing at the time. A process that remains active can still be stuck or repeatedly failing to send data, so “running” is not enough to confirm a live broadcast.
Review CPU, memory and disk pressure as well as network use. A media process can stop when it runs out of a resource, while a system can remain reachable in the Console. YouTube recommends checking the encoder’s output and CPU load when diagnosing encoder problems. Its live streaming troubleshooting steps are a useful reference, but the interface and commands for inspecting a Linux VM depend on your own deployment.
If the encoder log says it cannot open the input, verify the file path, permissions and available disk space. If it says the connection was lost, keep that timestamp for the network checks next. If it exits without a clear message, look for the process supervisor’s record of the exit and whether it attempted a restart. A supervisor can restart a process, but it cannot fix a bad key, unreadable input or blocked route; preserve the original error before changing configuration.
If you are using OBS on a VM, remember that its interface and settings are not universal to other encoders or Linux deployments. OBS describes dropped frames as a sign that the connection to the remote server is unstable or the configured bitrate cannot be sustained; enough dropped frames can disconnect the stream. Its connection troubleshooting guidance is specific to OBS. For a wider view of how to build and run a file-based channel, see this guide to a 24/7 YouTube lofi stream with OBS and VLC.
Check connectivity and YouTube ingest health
If the encoder is running and producing output, check whether it can reach YouTube. Review the encoder log for repeated connection attempts, timeouts, dropped frames or TLS/SSL errors. Then verify the VM’s outbound network path, including applicable egress rules, firewall configuration and routes. If you do not manage those settings, ask the administrator to confirm them; do not open broad network access simply to see whether the stream returns.
Compare the encoder’s view with YouTube’s Live Control Room. Stream health and its real-time metrics can show whether YouTube is receiving the feed and when an ingest warning began. A healthy-looking local encoder does not prove that the remote ingest is receiving usable video, so align the log timestamps with YouTube’s error times. If the Control Room shows no incoming signal while the VM has a continuing outbound connection error, focus on the route or encoder connection. If it shows a healthy incoming stream, investigate viewer playback separately.
Use the viewer reports as clues, not as a vote. One viewer having trouble may have a local playback or connection issue; several viewers on one network may share a network problem. If people on unrelated connections see the same interruption and Live Control Room also reports poor stream health, the issue is more likely to be upstream of those viewers. YouTube’s guidance on streaming issues can help interpret its status messages. A clean status at the time of checking does not prove there was no earlier disruption, so retain timestamps.
If the encoder output is healthy but the stream still cannot reach ingest, test outbound connectivity using tools appropriate to the VM and your provider configuration. A general internet check is not the same as verifying the route to YouTube’s ingest endpoint. Keep results private if they expose network details, and share only the relevant error text with your administrator or support channel.
Verify the encoder configuration and stream key
When logs point to a rejected connection or an encoder startup error, check the stream configuration in YouTube Studio’s Live Control Room. YouTube advises refreshing the stream key there and updating the encoder when a third-party encoder reports a startup error. A key may have been changed or copied incorrectly, but do not infer that from a generic disconnect. Treat the key like a password: never put it in a public issue, screenshot, or shared log, and redact it before asking for help.
For RTMPS, use the exact server URL shown in Live Control Room and confirm that your encoder supports RTMPS. If an SSL error persists, YouTube’s documentation suggests checking the RTMPS URL and port settings, including its documented port 443 guidance. Do not substitute a URL or port copied from an old tutorial. The stream key and encoder setup guidance is the source to check for the current event’s connection details.
Then review codec, bitrate, frame rate and keyframe interval against YouTube’s current encoder settings recommendations. YouTube lists recommended bitrate by codec, resolution and frame rate; those are ingest recommendations, not proof that a particular VM or route can sustain the chosen rate. For H.264, for example, its current guidance gives 6 Mbps for 1080p60 and 5 Mbps for 1080p30. A lower bitrate may be more stable when available outbound capacity is constrained, but the trade-off is reduced image detail. Choose a setting based on the actual stream and test it rather than assuming the maximum is appropriate.
| Check | What to verify | What the result suggests |
|---|---|---|
| Stream key | The key configured in the encoder matches the current one in Live Control Room | A mismatch can prevent encoder startup; keep the key private |
| Ingest URL | The URL is the one shown for this stream, with RTMPS if selected | A stale or incorrect destination can cause connection errors |
| Encoder support | The chosen encoder supports the selected protocol and codec | A feature mismatch can stop the encoder from connecting or sending usable video |
| Bitrate and output | The configured rate fits the stable outbound capacity and YouTube’s current recommendation | Excessive demand can lead to dropped frames or unstable output; lowering it trades quality for headroom |
| Keyframe interval | The encoder follows YouTube’s current recommendation | A setting outside guidance can make the feed harder to ingest reliably |
Make one configuration change, then verify the encoder’s output and Live Control Room status before changing another. For audio-only symptoms rather than a stopped feed, use the separate checks in fixing no sound on an ambient YouTube live stream. If the issue is specifically frames dropping when the bitrate is too high, this bitrate troubleshooting guide covers that case.
Check for YouTube stream or policy errors
A connection that reaches YouTube can still have a YouTube-side status or policy issue. In Live Control Room, read the precise stream health message and any warning attached to the event. Check the event’s status in YouTube Studio, including whether it is still live and whether an action or restriction is displayed. Do not treat an encoder reconnect as proof that the event is allowed to continue or that viewers can watch it.
If YouTube identifies an encoder or ingest error, follow the message and current Help guidance. If Studio displays a copyright, content or account notice, read the notice and use the appeal or support route described there where appropriate. A troubleshooting guide cannot determine your channel’s policy status, and an Always Free VM has no bearing on YouTube’s decision. Check the current official page rather than relying on an old screen capture or hearsay.
If the Control Room says the stream is healthy but viewers report a problem, compare the reports across networks and check playback from a separate connection. Avoid repeatedly ending and recreating an event without understanding the status: the event, encoder key and scheduled broadcast can be distinct pieces of configuration. Keep a note of the event identifier and the time of the warning, but never include the stream key in the note.
Recover carefully and monitor the restart
Once you have identified the affected layer, use the recovery procedure for that layer. If OCI shows a resource-state problem, follow the Console’s documented recovery route and verify that the data and volume you need remain available. If the VM is running but the streaming process exited, use the process manager or deployment-specific method to restart only that process. If the encoder is connected with the wrong key or URL, correct that setting using the details shown for the current YouTube event. Do not reboot the VM as a reflex when a process-level restart is sufficient.
After a restart, confirm each link in the chain: the process stays active, its output advances, outbound connection errors stop, and Live Control Room reports a healthy incoming stream. Then check playback from a viewer connection. These checks show that the service is working at that moment; they do not guarantee uninterrupted operation. If it fails again, compare the new timestamps and logs with the first incident rather than repeating all changes.
For a 24/7 channel, plan for detection as well as recovery. Retain enough logs to see process exits and connection failures, set an alert for a stopped encoder where your setup allows it, and write down the tested restart steps. A process supervisor may help restart a process after it exits, but it cannot resolve an OCI account state, a YouTube policy action or a network route fault. Test any backup encoder or failover arrangement in advance; YouTube’s live-stream advice includes testing the stream and monitoring its quality, and a backup path is only useful if you have actually verified it.
If repeated hands-on recovery is the part that makes an always-on channel difficult, StreamNeo removes the need to keep your own computer running by turning an uploaded video into a YouTube broadcast; it does not diagnose OCI tenancy issues or YouTube policy decisions. If you stay with your own VM, document the setup and test the restart path while you can observe it, not for the first time during an overnight interruption.
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
Can I tell from a stopped YouTube stream that Oracle reclaimed my VM?
No. A stopped stream could result from a stopped or disabled VM, a dead process, network trouble, encoder configuration, or a YouTube-side issue. Check the actual OCI state and notices before drawing a conclusion about reclaim.
Should I create a new Always Free instance if the stream stops?
Not before checking the existing instance state, notices, boot volume and application data. If you are seeing an out-of-host-capacity error while creating an instance, Oracle describes that as a temporary capacity issue for creation; try another availability domain where available or wait and retry. It is not automatically the explanation for an existing VM’s stream failure.
What should I do if the VM is running but the stream is offline?
Inspect the encoder or service process and its logs at the time of failure, then compare them with Live Control Room’s stream health and error timestamps. If the process output is healthy, check outbound connectivity and the current ingest URL and key; change only the layer indicated by the evidence.
Is lowering bitrate a fix for every interruption?
No. It can help when the configured rate exceeds stable outbound capacity, with a reduction in picture quality. It will not fix a stopped VM, a bad stream key, a YouTube policy message or an unrelated process failure.