When a YouTube stream connected through Castr ends unexpectedly, start in Castr’s Stream Session History and inspect the ended session’s Bitrate or Analytics health charts. Castr documents historical stream-health data, not a raw event-log viewer; the charts can show what changed around the stop, but they do not necessarily identify why YouTube ended the broadcast.
Act promptly: Castr says health-chart data is retained for 10 days, after which the session information is no longer available in that view. Record the session time and save relevant screenshots before moving on to checks in Castr or YouTube.
What Castr keeps for past streams
The useful distinction is between a record of stream health and a narrative log of events. Castr’s health charts documentation describes charts for past sessions, including video bitrate, audio bitrate and frame rate. Its guidance does not establish a separate interface that lists every event or reports YouTube’s exact termination reason.
That distinction affects what you should expect to find. A chart may show that video bitrate fell before the stream stopped, or that frame rate became unstable. It cannot, on its own, prove whether the cause was a weak upstream connection, an encoder problem, a destination setting, or an action taken in YouTube Live Control Room. Treat the visual pattern as a clue to test against other evidence.
Castr states that health data is kept for 10 days. If you are investigating a recent interruption, open the session and capture the relevant charts while they remain available. If the event is older, you may need to rely on saved screenshots, encoder records, network monitoring or YouTube’s own notices instead.
For a channel that runs continuously, it also helps to keep a simple incident note: the date and local time, the programme or file playing, what the audience saw, and any action you took. This is not a substitute for Castr’s charts, but it gives you a way to line up what you remember with the chart’s time axis. If the channel is built around a looping programme, the guide to streaming a looping video with fades can help you distinguish a planned transition in the content from an actual break in the broadcast.
Open Stream Session History
Sign in to the Castr dashboard and look for Stream Session History. Choose a date range that includes the interruption, then use Show Details to display past sessions. Dashboard labels can change; if you do not see the same wording, check Castr’s current help centre or ask support where the historical session view is located.
Make the selected range narrow enough to identify the right session, but broad enough to include the date and time you expect. If you run several channels or have restarted the stream more than once, compare the displayed session boundaries with your own notes. Do not assume the session you remember is the only one listed for that date.
If the stream stopped and was restarted, there may be separate sessions around the incident. Select the session that actually ended unexpectedly, rather than the later recovery session. A brief restart may also leave you with two useful views: the period leading up to the stop and the period after you resumed. Keep those distinct when making notes or sharing screenshots.
The history view helps narrow the investigation to a particular broadcast. It is not a record of every action taken in YouTube, and it may not tell you whether a human pressed a stop control. For a channel with a complicated schedule, write down which scheduled block was live at the time. The 24/7 YouTube channel planning guide is useful when you need a clearer operating schedule and handover record.
Select the ended session
Use the session date and duration to find the item that corresponds to the interruption. If you have a reliable local timestamp, compare it with the session details before opening its charts. Take care with time zones: your notes, Castr’s dashboard and YouTube’s displays might not present time in the same way. The key is to align the same moment, not to assume the labels match automatically.
If more than one session looks plausible, note the start and end times of each candidate. A session that ended around the reported stop is more relevant than one that began after you tried to recover. When you cannot tell which session is correct, inspect both and keep their evidence separate rather than combining patterns from different broadcasts.
Before proceeding, capture the session identifier or the identifying details visible in the dashboard, along with the date and time. Avoid sharing stream keys or account credentials in screenshots. Those are sensitive access details and are not needed for a support request about chart behaviour.
If the session details are absent, first check that the date range is correct and that the interruption falls within Castr’s stated retention period for health data. If it is still missing, use Castr’s support channel rather than inferring that the stream never reached the service. A missing historical chart and an unhealthy incoming feed are different observations.
Open Bitrate or Analytics health charts
From the selected session, open Bitrate or Analytics to reach the health charts. Castr’s documentation identifies video bitrate, audio bitrate and frame rate among the measures to inspect. The display is a timeline, so look at the lead-up to the interruption as well as the final point; the last visible sample may not explain what happened immediately afterwards.
Read each chart as a measurement of stream behaviour, not a diagnosis. A video-bitrate drop can be consistent with a connection issue, while dropped frames can be consistent with encoder or connection strain. Neither pattern alone names the failing component or confirms the reason YouTube stopped the broadcast. Compare the charts with what was happening at the source and with any status or message shown in YouTube.
If the chart appears flat or has a gap, do not immediately interpret it as proof that the source stopped. It could reflect the limits of the displayed data or the timing of the last measurement. Note what the chart actually shows and check the other available evidence before deciding what to change.
For a multi-part investigation, capture a broad view first, then a closer view around the stop. A broad view shows whether the interruption followed a longer period of instability or a sudden change. The closer view helps you compare chart behaviour with the time you recorded. Keep the screenshots clearly labelled so you can tell which session and time window each one represents.
Focus the charts on the interruption
Use Show Metrics Between to narrow the health charts to a time window around the interruption. Include some time before the reported stop, not only the moment at which the session ended. A useful window lets you see whether the readings were already moving in the wrong direction, changed abruptly, or remained steady until the visible data ended.
There is no single window that suits every interruption. Start with enough context to include the last stable part of the stream and the suspected break. If the chart suggests a change earlier than expected, widen the interval and see whether that pattern continues. If you know the time only approximately, use a broader range first, then narrow it once you locate the relevant part of the timeline.
Write down the selected interval and the time basis shown in your notes. This matters when you compare the chart with encoder logs, a router record or YouTube’s Live Control Room, because a mismatch in time zones can make unrelated events look connected. If you cannot confirm a chart’s time-zone convention from the interface, state that uncertainty when discussing the evidence.
Avoid reducing the investigation to a single screenshot of the final seconds. A chart that shows a falling bitrate followed by the stop is worth checking against the network and source. A chart that looks stable up to the end points you towards checking other layers, but still does not establish the exact reason. The method is comparison, not reading a definitive answer from one line.
Use chart patterns to investigate a disconnect
Start with the question of where the problem appears. If the charts show a deterioration in the incoming stream near the interruption, check the source encoder and the connection feeding Castr. If the measurements appear stable up to the end, look more closely at the destination setup and YouTube’s status messages. These are practical branches for investigation, not a validated decision tree, and a chart pattern cannot rule out a problem that it does not display.
For a source check, Castr’s troubleshooting guidance recommends H.264 video, AAC audio, constant bitrate (CBR) and a two-second keyframe interval. In its March 2026 article, Castr suggests 3,500–6,500 Kbps video for 1080p or 2,500–4,000 Kbps for 720p, plus 128 Kbps stereo audio. These are Castr’s recommendations, not universal requirements or guarantees that a stream will remain live. Compare your encoder’s actual settings with your intended output, and avoid changing several settings at once if you want to learn which change mattered.
For the network, Castr recommends upload capacity at least 1.5 times the stream bitrate and suggests wired Ethernet rather than Wi-Fi to reduce exposure to packet loss and latency spikes. In Castr’s example, a 5,000 Kbps stream calls for at least 7,500 Kbps (7.5 Mbps) of upload capacity. That is guidance from Castr’s article, not a guarantee of stability: available capacity can vary, and other devices may use the connection. If practical, test while the channel is running and check for competing uploads or changes in the network path.
If you use a computer-based setup for a continuous channel, check the encoder output and network at the same time as the Castr timeline. A mini PC continuous-stream guide discusses the source-computer side of an always-on broadcast. If the computer or home connection is the weak point, a cloud-run broadcast can remove the need to leave that machine running; StreamNeo turns an uploaded file into a YouTube live stream so the channel can continue without your computer being on. That removes one source of overnight interruptions, but it does not explain an earlier Castr session or guarantee that YouTube will keep every broadcast live.
Then check the destination. Castr’s older YouTube connection guidance discusses removing and reconnecting a YouTube destination and creating a fresh stream key when an existing key does not work. Before changing anything, verify the configured URL and key against YouTube’s Live Control Room, and confirm whether YouTube requires a separate go-live action for the broadcast. Treat older dashboard instructions cautiously because labels and workflows can change. Do not post a stream key in a support ticket or screenshot.
Castr also describes testing with a private or unlisted YouTube stream and watching Analytics > Input Health. A controlled test can help you see whether the feed reaching Castr appears healthy without presenting an unplanned interruption to viewers. Check YouTube’s current Live Control Room guidance for the current destination-side workflow and status information. A healthy-looking input does not by itself prove the whole route to viewers is working, so record what each interface reports.
Compare evidence and preserve useful details
Build a short timeline before making a major change. Put the reported stop time beside the relevant Castr chart observations, encoder notices, network changes and any YouTube messages. Separate direct observations from interpretations: “video bitrate dropped” is an observation; “the Wi-Fi caused YouTube to stop” is a theory until independently supported.
A simple comparison helps prevent jumping to conclusions:
| Evidence near the stop | What it can suggest | What to check next |
|---|---|---|
| Video bitrate falls or becomes erratic | The incoming video feed may have been affected | Encoder output, upload capacity and network changes |
| Frame rate drops or frames are reported as dropped | The source or connection may be under strain | Encoder workload, source settings and network stability |
| Audio changes while video remains steady | An audio-source or audio-encoding issue may be involved | Audio input, AAC configuration and source playback |
| Charts look steady until the session ends | The cause may be outside the visible chart evidence | YouTube Live Control Room, destination configuration and operator actions |
| No chart is available for the session | The session, selected date range or retention may be an issue | Confirm the range, date and current Castr support guidance |
These are investigation prompts rather than automatic diagnoses. The same pattern can have more than one explanation, and the table does not assign probabilities. If evidence conflicts—for example, Castr shows a healthy feed while YouTube displays a destination warning—keep both facts and investigate the layer each one describes.
For a repeat test, use a private or unlisted broadcast if that suits your channel, then watch Castr’s Input Health view and YouTube’s status at the same time. Record the test time, output settings and any warning text. A test can narrow down where the feed changes, but it cannot guarantee that a later long-running session will behave identically.
When contacting support, include the session time, the chart interval, what the video, audio and frame-rate charts show, and the steps already tried. Include screenshots with credentials obscured. If the charts do not account for the stop, say so plainly and ask Castr or YouTube support about the evidence from their respective side. Do not ask a chart to supply a termination reason that it does not claim to provide.
Reduce the cost of the next interruption
Once you have investigated the incident, change one relevant thing at a time and keep a record of the result. If the evidence points towards the source, test a stable encoder configuration before adjusting the destination. If it points towards the network, compare wired and wireless operation where possible and check upload use during the stream. If it points towards YouTube, verify the current destination configuration and read the message shown in Live Control Room.
If you operate a devotional, music or ambience channel overnight, consider how you will notice a stop while away from the screen. Castr documents SMS alerts for stream-down events on Premium or higher plans, with a stated limit of 20 alerts per month and one configured phone number per account; those plan and limit details are from Castr’s July 2026 help article, and you should confirm current availability in your account before relying on them. An alert tells you to investigate, not why the stream ended.
Keep a small incident record with the date, session details, screenshots, settings, and the outcome of each test. Over time, this helps you distinguish repeated source or network patterns from one-off destination issues without pretending that correlation proves cause. If your channel depends on a single always-on machine, the cloud-based playout setup guide can help you weigh the operational trade-offs before changing how the channel runs.
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 Castr show raw logs for an ended YouTube stream?
Castr’s published guidance describes historical health charts rather than a raw event-log viewer. Use the session history and charts to inspect stream behaviour, then check YouTube’s own status information if you need evidence from the destination side.
How long are Castr health charts available?
Castr says stream health data is retained for 10 days. If the interruption is recent, capture the chart details promptly; for an older session, look for records you saved at the time or contact Castr support to ask what remains available.
Can a bitrate drop tell me exactly why YouTube ended the stream?
No. Castr says a sudden video-bitrate drop can indicate a connection issue, but that is a clue, not a conclusive explanation of YouTube’s decision. Compare it with frame-rate behaviour, encoder and network evidence, and messages in YouTube Live Control Room.
What should I send Castr support if the charts do not explain the stop?
Give them the session date and time, the time range you inspected, and screenshots of the relevant charts with keys and credentials hidden. Describe what you checked in the encoder, network and YouTube destination, and distinguish observed facts from your best explanation.