If Restreamer shows offline on YouTube even though the stream is running, first confirm which Restream product you mean, then check the outbound publication rather than relying on local playback. A working source or preview shows only that part of the path is active; YouTube’s Live Control Room and the publication process provide separate evidence about whether the feed is reaching the intended event.
The useful distinction is between the source, the local stream, the outbound connection and YouTube’s ingest status. Work through those layers in order, noting what each one actually proves. Do not change stream keys or rebuild the source until the evidence points to a configuration or process problem.
First identify which Restream you use
“Restreamer” can refer to datarhei Restreamer, the self-hosted streaming application, or to Restream.io, a hosted multistreaming service. They have different interfaces and connection models. The checks below concern datarhei Restreamer unless stated otherwise: it uses a Publication Service to send a feed to YouTube. Restream.io users should use its own channel-connection controls and support instructions instead of looking for datarhei process details.
Check the product name in the interface, its version, and where the offline status appears. Is it a message in YouTube Studio, a publication indicator in datarhei Restreamer, or a status in Restream.io? Record the exact wording. An offline label in one place does not necessarily describe the state shown by another system.
Datarhei’s YouTube guide for Restreamer describes setting up a YouTube Publication Service with a streaming ID. Its troubleshooting guide separates problems with video input, player streaming and the Publication Service. The Restream.io support article applies only if that is the product you are using. Datarhei’s documentation may show labels that differ from your installed version, so note the version rather than assuming an older screenshot matches your screen.
Local playback and YouTube status are separate checks
A local player can show that Restreamer has video to play. It does not prove that the Publication Service is active, that it is sending data to YouTube, or that YouTube has associated that data with the event you intend to run. Think of the route as several hand-offs: source to Restreamer, Restreamer to its local player, publication process to YouTube, and YouTube ingest to the Live Control Room. Each needs its own evidence.
This distinction matters when a devotional loop, study stream or local news playlist keeps moving on your monitor while YouTube still reports offline. The preview may be receiving a healthy feed from a camera, file or other input even when the outbound destination is disconnected, misconfigured or aimed at a different event. Conversely, a message in YouTube Studio may take time to reflect a change, so compare it with the publication’s current state rather than treating any single indicator as a full diagnosis.
Datarhei’s basic troubleshooting guide treats input, player and Publication Service as distinct areas to inspect. Keep that separation in your notes. For example, write down “local player moving” as source/player evidence, not as proof that YouTube is receiving the feed. This avoids chasing a source fault when the problem lies at the outbound step, or changing a working publication because a source preview looks unusual.
A simple comparison table can keep the checks straight:
| Evidence you see | What it can tell you | What it does not establish |
|---|---|---|
| Source or local player is active | Restreamer has something to play locally | That a YouTube publication is connected |
| Publication Service shows bitrate | The publication has a live data rate shown in Restreamer | That it targets the intended YouTube event or that YouTube has accepted the feed |
| Process details show an active process | The publication process is running at that point | That it has no errors or is delivering usable data |
| YouTube Live Control Room shows incoming preview or encoder status | YouTube is reporting an incoming feed for that event | That every viewer can watch it or that the event is configured as intended |
Use the table as a way to label evidence, not as a pass/fail checklist. A displayed bitrate and a YouTube preview are stronger when they agree, but either should be interpreted alongside the selected destination and the current event.
Check the Publication Service bitrate
In datarhei Restreamer, open the active YouTube Publication Service and check that it is the service you expect to use. Datarhei’s publication documentation describes the service as the outbound connection and says its bitrate is displayed in the main Restreamer window once connected. If the publication has no displayed bitrate or is not shown as active, that is a reason to inspect the publication process, not a reason to conclude immediately that the source has failed.
Check whether the service is configured for the right destination and whether it is currently enabled or running according to your version’s interface. Make a note of the state and bitrate before stopping or editing anything. If the figure appears and then disappears, note when that happens and whether it follows a source change, a YouTube event change or a network interruption. A brief observation is more useful than repeated restarts with no record of what changed.
A bitrate is evidence about the publication process, but it does not by itself confirm that the correct YouTube event is receiving the feed. Pair it with the event and key check in YouTube Studio. If the bitrate is absent, use the process details and logs next; if it is present but Studio remains offline, verify destination settings and the event before assuming an encoder or source problem.
For a broader view of how an encoder sends a feed, the blog’s OBS or FFmpeg automation comparison explains the difference between producing a stream and automating its delivery. Its examples are not a substitute for your Restreamer interface, but the distinction is useful when tracing which component has actually connected.
Inspect process details and logs
Open the details for the YouTube publication process, not only the source process or local player. Look for whether it is running, whether it reports an error, and whether the details suggest that it is repeatedly starting and stopping. Use the logs and any process report available in your version. Record the relevant messages and times; do not expose stream keys or other credentials when sharing that material.
A process can be active and still fail to deliver a usable feed. The details and logs help distinguish a process that never starts from one that starts but encounters an error, or one that is publishing while YouTube shows a different status. Datarhei’s troubleshooting instructions recommend examining the process and, when escalating after initial checks, attaching a process report. If interface labels vary, provide the software version with the report so someone can interpret what you captured.
Avoid treating a single error line in isolation as a confirmed cause. Compare its timestamp with the bitrate display, source state and YouTube’s status. If you changed a setting, note exactly which one and whether the process restarted afterwards. This gives you a before-and-after record instead of a trail of undocumented changes.
If you need to ask for help, gather the Restreamer version, the exact status text, whether YouTube shows an incoming preview, publication settings with the key redacted, relevant process details and logs, and a process report if available. Never paste a stream key into a public forum, screenshot or support ticket. Someone with the evidence can help identify the failing hand-off without needing your credentials.
Verify the YouTube destination configuration
Confirm that the YouTube Publication Service is configured with the stream ID or key for the event you are trying to run. YouTube’s live streaming settings explain the role of the stream URL and key in an encoder setup. The exact entry fields depend on the Restreamer version, but the question is the same: does the outbound service use the destination details for this event, rather than an older event or another channel?
In YouTube Studio, open the relevant scheduled or live event and compare its settings with the destination in Restreamer. Check that you are looking at the right channel and event, not merely a previous stream with a similar title. A correct key for one event will not make a feed appear in another event. If you manage several channels or recurring streams, label your own notes clearly so that a key or service name cannot be mistaken for another programme.
Do not reset the key as a routine first step. YouTube’s troubleshooting guidance advises obtaining a new stream key and updating the encoder when the encoder reports a startup error or the evidence indicates a key problem. If you do reset it, update the corresponding Restreamer destination and confirm that the publication uses the new value. A reset that is not followed through can create another mismatch. Keep keys private throughout the process.
For continuous streams, it can help to keep a brief destination record: channel, event, service name and the date you last checked the key, without writing the secret key itself in an exposed document. If your setup also uses a separate computer or cloud encoder, distinguish its settings from Restreamer’s. The guide to continuous YouTube streaming from a low-cost Indian VPS discusses another delivery arrangement; the important point here is to identify which component holds the active destination credentials.
Compare the result with Live Control Room
Open YouTube Studio’s Live Control Room for the intended event and check what it reports about the incoming encoder feed or preview. YouTube’s live stream troubleshooting page recommends checking encoder messages and stream health. Read the status and any message there alongside the publication bitrate and process details. The goal is to find where the two systems disagree, not to let one label overrule all the other evidence.
If Restreamer shows a publication bitrate but the expected event has no incoming preview, first recheck the event, channel and destination credentials. If the event shows an incoming feed while Restreamer’s local player looks wrong, the source or local playback path may need separate attention. If both show evidence of a feed but the event remains in a state you do not expect, read YouTube’s current message and check the event’s configuration before stopping it or creating another event.
Status changes may not appear at precisely the same moment in both interfaces. Refresh the relevant views and allow the systems to report their current state, but do not use waiting as a substitute for checking the destination or logs. YouTube’s official guidance is the place to verify current explanations for its encoder status messages, because the wording and interface can change.
If you are already on air, use care before stopping a process. Datarhei’s YouTube guide advises ending the stream on YouTube first; stopping in Restreamer during a live stream may prevent YouTube from saving the DVR archive. Check the current event and the guide before choosing how to end or restart a live broadcast, particularly if the archive matters to your audience.
The blog’s guide to Live Control Room and cloud playout is useful context for understanding the difference between YouTube’s event controls and the system producing or delivering the programme. It does not replace checking the exact event that is open in your own Studio account.
Trace the source, encoder and outbound network
If the destination and event appear correct, isolate the source from the publication path rather than changing several settings at once. Datarhei’s troubleshooting approach includes using a virtual or test source. If a test source also fails to publish, that makes the original camera, playlist or media file a less direct suspect and puts the publication process, destination and transport path higher on the list. If the test source works, return to the original input and inspect how it reaches Restreamer.
For a file-based stream, confirm that the intended media is still being read and that the source process has not ended or stalled. For a camera or another live input, check the input’s own connection and whether Restreamer continues receiving it. These checks answer whether the source reaches Restreamer; they still do not establish that YouTube receives the outbound feed. Keep the source evidence separate from publication evidence in your notes.
Then check the encoder process and the outbound internet path. YouTube recommends using a current encoder, reviewing stream health and encoder messages, and examining outbound connectivity when the encoded stream appears healthy but does not reach the platform as expected. If the setup runs on a VPS or a dedicated machine, assess whether that machine can maintain its outbound connection and whether the issue coincides with changes or interruptions in its network. Do not infer a specific fault from the country, provider or type of connection alone.
A local preview can look steady while an outbound route is unstable, and a network test from your personal laptop may not represent the route used by the machine running Restreamer. Test from the system that actually runs the publication when practical. If the connection problem is intermittent, record when the publication bitrate drops and compare those times with process logs and YouTube’s event messages. That timeline is more useful than a general note that the internet “seems fine”.
For a stream that has to continue while your own computer is off, separate the operational question from this diagnosis: first establish which source and destination are active and what YouTube reports. StreamNeo can remove the need to leave a personal computer running by taking an uploaded video and sending it as a YouTube live stream, but it does not diagnose or repair a datarhei Restreamer publication that is already configured. It is YouTube-only, so it is relevant only if changing the delivery arrangement fits your channel.
When the evidence still conflicts, stop making broad changes. Save the exact status text, version, event details, redacted destination settings, bitrate observations and process report. Then ask for help with a description such as “source is active, publication bitrate is absent, and the intended event shows no preview,” rather than simply saying the stream runs. That states what you know without turning a local observation into a claim about YouTube ingest.
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 my local Restreamer player work while YouTube says offline?
The player and the YouTube publication are different parts of the path. A local preview shows that Restreamer can play video locally, but you still need to check the Publication Service, its process evidence and the intended event in YouTube Live Control Room.
Should I change my YouTube stream key straight away?
No. First confirm that the service points to the intended event and compare its process messages with YouTube’s encoder status. Replace the key when the evidence indicates a key or startup problem, and update the destination that actually publishes the feed.
What should I include when asking for support?
Share the product and version, exact status wording, whether the intended event shows an incoming preview, the publication bitrate observation and relevant process details or logs. Redact the stream key and include a process report if available; never publish credentials.
Is this guidance for Restream.io as well?
The process and Publication Service instructions are for datarhei Restreamer. Restream.io uses a different connection model, so confirm the product first and use its support guidance for channel-connection issues.