An “offline” message after an Ubuntu restart can refer to three different things: the Owncast website cannot be reached, Owncast is up but receiving no broadcast, or Owncast is receiving video while YouTube has no outgoing stream. Check those paths separately; a working web page does not prove that either publishing path has resumed.
First identify whether your installation is a native systemd service or a Docker container, then inspect the failing path. systemd can start and restart a service, but restarting Owncast alone does not establish that an encoder reconnects or that a separate YouTube output is publishing.
Identify which service appears offline
Write down exactly where you see “offline” before changing settings. Can you open the Owncast site or admin interface? Does the Owncast player show a feed? Does YouTube Live Control Room show an incoming stream? These observations point to different components, and fixing one does not necessarily fix the others.
| What you observe | What it tells you | First place to check |
|---|---|---|
| Owncast website will not load | The web service, host, route or web port may be unavailable | Service or container state, startup logs, and web access on port 8080 |
| Website loads, but its player is offline | Owncast may be running without an incoming broadcast | Broadcaster status, /live destination, Owncast stream key and RTMP access on port 1935 |
| Owncast shows video, but YouTube is offline | Incoming Owncast video is not proof of an outgoing YouTube feed | The actual relay or second-encoder route, YouTube destination and YouTube stream key |
| Service starts, then exits or repeatedly restarts | A startup or runtime fault may be occurring | Current-boot logs, executable path, account permissions and data access |
This distinction also helps when someone else manages one part of the setup. The Owncast administrator may be able to confirm the incoming feed, while a separate broadcaster or relay operator controls YouTube publishing. Ask who owns each path rather than assuming that one dashboard describes the whole chain.
If you run a prerecorded or looped programme through an encoder, keep that sending process in view as well as Owncast. A restart can interrupt the encoder on another machine even if Ubuntu starts Owncast correctly. For the sending side, the practical checks in a continuous YouTube stream from a computer are relevant: confirm which device is actually producing and sending the programme.
Check Owncast web reachability and incoming broadcast
Open the Owncast web address from a device outside the Ubuntu machine if possible. If it does not load, first check whether the machine is running and whether its web service is listening and reachable. Owncast's manual installation documentation identifies port 8080 for the web interface and port 1935 for RTMP ingest; these are different network paths, not interchangeable ports. See the Owncast installation guide for the documented endpoints and installation context.
If the page loads, treat that as evidence that the web path is available, not that video is arriving. Look at the player or status area, then check the encoder that publishes to Owncast. Its destination should point to Owncast's /live RTMP endpoint and use the Owncast ingest key configured for that server. Do not use a YouTube key in that field: the two keys belong to different destinations.
When no video arrives, verify that the encoder is running and attempting to publish. Confirm the address, endpoint path and key in the encoder's settings without copying the key into a ticket, screenshot or public post. If the encoder runs on a different network, check that port 1935 is allowed by the Ubuntu host firewall and any cloud firewall or security rule in front of the server. A reachable web page on port 8080 does not demonstrate that RTMP traffic can reach port 1935.
A helpful test is to note the time you restart the encoder and watch Owncast's logs for a corresponding connection. If the server records no attempt, the sender may not be running, may be using the wrong address, or may be blocked before it reaches Owncast. If it records a rejected attempt, compare the key and endpoint against the values configured on the Owncast side. If it connects and then disconnects, investigate the sender and network stability instead of repeatedly editing the service unit.
Verify the systemd unit and startup configuration
These systemd checks apply to a native Owncast installation. If you installed Owncast in Docker, skip to the container note below: systemctl status owncast does not report a separately managed container as though it were a native unit.
Start with the current state:
sudo systemctl status owncast
This tells you whether systemd knows a unit called owncast and whether it is active, failed or missing. If it is missing, confirm how you installed Owncast and what the unit is called before creating a new one. A foreground command that worked in a terminal does not automatically run at boot as a system service.
For a native installation, compare your unit with Owncast's systemd service guidance. Its example includes a boot target, a restart policy, a short restart delay and paths and account fields that must match the installation. In particular, check ExecStart, WorkingDirectory, User and Group; sample paths from documentation are examples, not values to paste without inspection.
If you edit the unit, tell systemd to reload its configuration before restarting the service. To arrange for a native unit to start at boot, Owncast documents enabling it with sudo systemctl enable --now owncast. Check the result afterwards with systemctl status; do not treat the command completing as proof that the application is receiving a broadcast.
A restart policy handles a process that exits according to the unit's configuration. It does not prove that an external encoder will reconnect, and it cannot verify a second output to YouTube. After reboot, check both the Owncast unit and the broadcaster rather than assuming that service startup has restored the full programme.
For Docker, use the restart instructions for the container deployment rather than adding a native systemd unit for the same purpose. Owncast documents a Docker restart policy such as --restart unless-stopped and persistent data storage in its container guidance. Check the container's own state and logs, and confirm that the data mount survives the host restart. The policy and Compose configuration are deployment-specific; do not mix container instructions with a native service recipe.
Check the service user and working directory
A service can exist and still fail at startup because it runs from the wrong directory or under an account that cannot access its files. Owncast recommends a dedicated non-root service account. The WorkingDirectory should be the directory that contains the Owncast executable and its data/ directory, while ExecStart should identify the executable at its actual location.
Check that the configured service user can read and execute the binary and can write where Owncast needs to keep its data. A unit that runs successfully under your login account may fail under its service account because the latter has different permissions and a different environment. Avoid solving this by running the application as root; first correct ownership and access for the intended account and paths.
Systemd hardening can introduce another write restriction. If your unit uses ProtectSystem=strict, Owncast's documented guidance calls for an appropriate ReadWritePaths entry so its data directory remains writable. Confirm the exact path in your unit and ensure that it is the same directory the service uses. A restrictive setting without an allowed write path can produce a process that starts and then cannot save needed data.
When changing a unit or permissions, make one change at a time and check the status and logs again. Record the original values before editing. This is easier to reverse than changing the service account, executable path, directory ownership and hardening settings together, then trying to infer which change mattered.
Inspect logs after restart
For a native service, inspect this boot's journal soon after the restart:
sudo journalctl -u owncast -b --no-pager
The -b option narrows the output to the current boot, which is useful when older successful runs obscure the present failure. To watch new messages while you try a connection, Owncast also documents following the unit with journalctl -u owncast -f. Stop the live view when you have captured the relevant attempt.
Read the sequence around the first error, not only the last line. A missing executable or directory points towards ExecStart or WorkingDirectory; a permission denial points towards the service account or file access; repeated starts and exits warrant checking the full startup message and unit settings. If logs show Owncast started normally but no incoming connection, move to the encoder and network path instead of treating an active process as a live feed.
When testing an encoder reconnect, note the time, destination and the result shown in the sender. Then check whether the journal contains a matching connection, rejection or disconnect. No entry suggests that the publishing attempt may not be reaching the Owncast process. A key rejection makes the Owncast-side key and the encoder's configured key the next comparison; a successful connection shifts attention to whether the video feed continues and whether a separate output is configured.
Keep credentials out of logs shared with others. Stream keys are secrets: redact them in screenshots and support posts, and do not paste them into shell commands that might be retained in history. Logs should help identify the failing step without exposing access to your channel.
Test the separate YouTube output
If Owncast is reachable and receiving video but YouTube still reports offline, stop changing the Owncast startup unit for the moment. Identify the actual route from the incoming feed to YouTube. It may use a second output from an encoder, a relay or another publishing tool; Owncast being online does not by itself establish that any of these is active.
Check the component that sends to YouTube. Is it running after the Ubuntu restart? Is its YouTube destination selected, and does its status show an active connection? If the same encoder sends to both destinations, inspect each output separately. A working Owncast connection can coexist with a failed YouTube connection because the endpoints and credentials are distinct.
In YouTube Live Control Room, check the stream's status and settings. YouTube's stream settings help explains where the stream key is managed and entered into an encoder. If you reset the YouTube key, update the destination that publishes to YouTube with the newly generated key. Do not replace the Owncast ingest key with it, or assume that changing one updates the other.
If the setup uses a relay, inspect its logs and configuration between Owncast and YouTube. Confirm whether it has resumed after the host restart, whether it is pulling from the correct Owncast feed, and whether it is publishing to the intended YouTube event. If you do not know the topology, map it before editing anything: name the incoming sender, Owncast, any relay or second encoder, and the YouTube destination. That small diagram prevents fixing a component that was never responsible for the missing output.
A brief controlled test is more useful than changing multiple keys or restarting every component at once. Observe Owncast receiving video, then observe the relay or encoder's YouTube output, then confirm what Live Control Room reports. If an output fails, preserve the relevant timestamps and redact keys before asking for help. A YouTube-side offline status may have causes outside the Ubuntu service, so use YouTube's current official guidance for the status you see.
If the broadcaster itself is a desktop encoder, a restart on the Ubuntu host may not restart that encoder at all. Check its operating-system startup behaviour, saved scene or profile, and whether it reconnects to the right destination. A practical OBS setup for a continuous ambience stream is useful background for checking encoder-side configuration, though your actual network and publishing topology may differ.
Make the next restart easier to diagnose
Before the next planned restart, note the installation type, unit or Compose service name, Owncast web address, broadcaster destination and which tool handles YouTube output. Store keys securely, not in a shared handover note. With that map, you can check the same points in order rather than guessing from a single offline label.
After reboot, work from the host outward: confirm the native unit or container is running; open the Owncast site; verify an incoming connection; then verify the distinct YouTube output. Keep a short record of which observation failed and the corresponding log time. If the site is inaccessible, focus on host and service startup. If only ingest is missing, focus on the sender and RTMP route. If only YouTube is missing, focus on its publishing path and current stream settings.
For a looped or playlist-based programme, treat edits and restart behaviour as separate operational questions. A service restart can interrupt the current session without changing the media file, while a file edit may affect the sender independently. The cautious approach in updating a YouTube Live playlist without stopping the stream is relevant when you are diagnosing a programme source as well as the server.
If maintaining a Linux host, permissions, updates and separate publishing paths is more work than you want to own, choose an approach based on the task you need done. StreamNeo is relevant when the specific pain is keeping a file-based YouTube broadcast running without leaving your own computer on; it does not repair an Owncast server or turn Owncast into a YouTube relay.
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
Why does the Owncast page load while the player says offline?
The web interface and the incoming RTMP broadcast are separate paths. Confirm that the encoder is running, points to Owncast's /live endpoint and uses the Owncast key, then check whether a publishing attempt appears in Owncast's logs.
Does enabling systemd restart restore the whole stream?
No. A systemd unit can start or restart the Owncast process according to its configuration, but that does not prove an external encoder reconnects or that a separate YouTube output is active. Check each publishing path after the host starts.
Should I use the YouTube key in Owncast?
No. Owncast's ingest key is for the broadcaster sending video to Owncast; the YouTube key belongs to the output that publishes to YouTube. If you reset the YouTube key, update the encoder or relay that sends to YouTube, not the Owncast ingest setting.
What if Owncast runs in Docker rather than systemd?
Use the container's status and logs, and check its restart policy and persistent data configuration against Owncast's container instructions. A native systemctl status owncast check is not a substitute for inspecting a separately managed container.