A Switchboard Live stream that keeps reconnecting can be failing at the encoder-to-Switchboard link or at the hand-off from Switchboard to YouTube. Check those links in order: first confirm what Switchboard is receiving, then verify the workflow credentials, and compare the time of any YouTube error with the encoder’s report.
Do not begin by changing every key or restarting every part of the setup. Each monitoring point tells you something different. A “Not receiving video” status on Switchboard points you towards the incoming feed; a timestamped error in YouTube Live Control Room can point to a problem with the stream reaching YouTube.
Map the route before changing anything
Think of the broadcast as two connections with three useful places to observe it: encoder → Switchboard workflow → YouTube. Your encoder sends video to the selected Switchboard workflow. Switchboard receives that feed and forwards it to the configured YouTube destination. A reconnect message from the encoder is not, on its own, proof that YouTube is the part dropping.
Start by noting what each place reports at roughly the same time. Does the encoder say it is reconnecting? Does Switchboard still show an incoming picture and stream details? Does YouTube show a health warning or an error with a timestamp? These observations help locate the break without treating the whole chain as one connection.
| What you observe | Link to investigate first | What to check next |
|---|---|---|
| Encoder reports reconnecting and Switchboard says it is not receiving video | Encoder to Switchboard | Encoder state, selected workflow, server URL and ingest key |
| Switchboard continues receiving video but YouTube reports an error | Switchboard to YouTube | YouTube Live Control Room health message, its time and the reported setting |
| Encoder preview or local output is already faulty | Before the feed reaches Switchboard | Source, encoder software, audio/video output and computer load |
| Statuses disagree or the failure is brief | Not yet isolated | Capture times and logs before changing a setting |
The table is a diagnostic starting point, not a promise that every fault will fit one row. A short network interruption, for example, may leave different screens showing different states for a while. If you need a comparison for a different encoder and YouTube symptom, see this guide to an FFmpeg stream reconnecting on YouTube Live; the same principle applies: identify which part of the route lost the feed before changing settings.
Check what Switchboard is receiving
Open the selected Switchboard workflow while the encoder is supposed to be live. Its confidence monitor is the first check: it previews the video arriving from the encoder. Switchboard’s help page describes the missing-feed status as “Not receiving video”. If that is what you see, Switchboard has no incoming video to forward to the destination, so begin at the encoder-to-workflow connection rather than adjusting YouTube settings.
If the preview is blank, confirm that the encoder is running and actually sending. Some encoders have a separate Go Live action; an open project or a running preview does not necessarily mean it is transmitting. Also check that you are looking at the workflow selected in the encoder, rather than another workflow with similar content or a previous configuration.
When video is arriving, inspect the workflow’s displayed stream status and, where available, bitrate and frames per second (FPS). These details help distinguish a live feed from a frozen preview or an encoder that has stopped sending. They do not establish that YouTube is receiving a healthy stream. Switchboard’s guide to its workflow page explains where workflow status and stream details are shown; interface labels can change, so use the current page as your reference.
Treat the confidence monitor as evidence about one leg only. A visible picture means Switchboard is receiving video; it does not by itself confirm that the destination is configured correctly or that YouTube accepts the stream. Conversely, if the monitor has no picture, changing YouTube’s stream format before restoring the incoming feed is unlikely to address the observed problem.
Verify the workflow address and key
An encoder sends to an ingest endpoint using a server URL and a key. For Switchboard input, those values must match the ones displayed for the workflow you intend to use. Compare them carefully rather than relying on memory: confirm the selected workflow, the server URL field and the corresponding key field. If a workflow was reset or its details changed, refresh the encoder with the current values shown there.
Keep the two services’ credentials separate. The Switchboard workflow URL and key tell your encoder where to send its feed; the YouTube stream key is for the connection that sends video to YouTube. They are not interchangeable. Replacing both in response to one error can obscure the original fault or break a connection that was working.
Use the error’s source to decide which credential, if any, to refresh. If Switchboard shows no incoming video and the encoder reports an ingest connection problem, inspect the Switchboard workflow values. If Switchboard is receiving video but YouTube says the encoder cannot start or its stream key is wrong, follow YouTube’s instructions for the YouTube key instead. YouTube’s troubleshooting guide for an encoder startup error directs creators to Live Control Room’s Stream area to copy the key into the encoder that connects to YouTube. In a routed workflow, take care to update the setting on the connection named by the error, not an unrelated credential.
Do not post either key in a public support thread or screenshot. If you need help, share the exact error and describe which credential field you checked; redact the key itself. This keeps the diagnostic useful without exposing access details.
Read YouTube’s Live Control Room errors
When Switchboard is still receiving the feed, move to YouTube Live Control Room and check the stream health indicator and the time shown beside any error. YouTube distinguishes critical red errors, which can prevent an event from starting or cause viewer problems, from yellow warnings that may reduce quality. The message and timestamp are more useful than a general impression that the stream “looks unstable”.
YouTube’s official live-stream troubleshooting page lists issues that can include format or codec, bitrate, audio/video settings, keyframe frequency, resolution and mismatched primary or backup settings. Read the actual wording in your Control Room and correct the reported item. For instance, a format error calls for reviewing the encoder’s output format; it is not a reason to change the Switchboard ingest key when Switchboard is visibly receiving video.
Compare the time of the YouTube error with the encoder log and Switchboard status. If the encoder and Switchboard were still active at that moment, focus on the YouTube destination configuration or the property YouTube names. If Switchboard lost its incoming feed at the same time, investigate the earlier link as well. A timestamp is a clue to the sequence, not proof of a single cause.
A stream health message can also be transient. Record it before making a change, then see whether it recurs after one targeted adjustment. Changing resolution, bitrate, keyframe interval and credentials together may make the error disappear, but it will not tell you which change mattered, and it may introduce a new mismatch.
Check the encoder and outbound connection
If Switchboard is not receiving video, or the local output looks poor before it reaches Switchboard, inspect the encoder itself. YouTube recommends using current encoder software, checking the stream directly in the encoder, looking for encoder errors and checking CPU load. A local preview that freezes, loses sound or shows the wrong source points to a different problem from a clean local output that fails only during delivery.
Check that the correct audio and video sources are selected and that the encoder has not stopped or been overloaded. If practical, test the same source with another encoder as a diagnostic, not as an automatic replacement. For a 24/7 channel, record the software version and the time the encoder reports a reconnect; that gives you something specific to compare if the fault returns overnight.
Then check the outbound connection from the encoder’s location. Switchboard emphasises upload connectivity for live streaming, but there is no universal speed threshold that diagnoses every setup. Test the connection while the issue is present if possible, and distinguish a local wireless problem from a broader internet or ISP fault. Trying wired Ethernet instead of Wi-Fi can isolate one possible local-network factor; it is a test, not a guaranteed repair.
If a connection test exposes a problem, contact the ISP with the test result and the times of the dropouts. If the encoder’s local output is faulty even when the connection is stable, focus on the source or encoding setup instead. These are separate checks: an internet test cannot correct a bad audio source, and changing an audio codec cannot repair a dropped local connection.
Retest one link at a time
Once the observations point to a link, make one change that addresses it and check the same monitoring points again. If Switchboard lacks input, verify the workflow URL and key or restore the encoder’s Go Live state; then confirm whether its confidence monitor receives video. If Switchboard receives video but YouTube reports a key error, refresh the YouTube key in the relevant connection and watch for the specific error to clear.
If YouTube names a stream property, adjust that property rather than changing unrelated settings. Keep a brief before-and-after note: the setting changed, when you changed it, and what each monitor showed afterwards. If the status improves but another warning appears, capture that message before making a second adjustment.
Protocol choice is a later consideration, not the first response to reconnects. Switchboard describes RTMP as broadly compatible and suitable for most users, RTMPS as encrypted RTMP, and SRT as an option for low-latency streaming on unstable networks. If both the encoder and workflow support SRT and the network is unpredictable, you could evaluate it as a controlled test. Do not assume a protocol change will solve every YouTube reconnect, and confirm compatibility before switching.
For a new configuration or a change you want to observe without affecting viewers, a private test can help you separate setup errors from a public broadcast. This walk-through of testing an FFmpeg YouTube stream privately is relevant if FFmpeg is your encoder. If your main concern is whether a loop can continue after a home internet drop, see the separate recovery options for a YouTube playlist stream in India; that is a different question from locating a failing Switchboard link.
For a channel that should continue when your own computer is off, a cloud-run broadcast removes the need to keep that computer encoding overnight. StreamNeo turns an uploaded video into a 24/7 YouTube live stream, which can remove the specific burden of maintaining a local encoder for a file-based channel; it is YouTube-only and does not diagnose a Switchboard workflow already in use.
Keep a useful reconnect record
When a disconnect repeats, write down the local time and timezone, then collect what each layer reported around it. Useful evidence includes the encoder’s exact log or error, whether its local preview continued, Switchboard’s incoming status and any displayed bitrate or FPS, and the exact YouTube error text with its timestamp. A short record is more useful than a note that says only “it dropped again”.
Keep the notes in a simple table so repeated events can be compared:
| Time and timezone | Encoder report | Switchboard status | YouTube report | Change made |
|---|---|---|---|---|
| At the time of a dropout | Exact reconnect text or log excerpt | Receiving video, or not receiving video; include details shown | Exact message and displayed timestamp | One adjustment, or none |
Avoid recording stream keys or passwords in the table. If you need to share a screenshot or log with support, redact credentials and include the surrounding error text. For long-running devotional, ambience or study channels, consistent notes make it easier to tell whether drops happen at a particular time, after a software change or alongside a broader connection problem, without assuming that the pattern proves a cause.
If the problem persists, send Switchboard support the workflow status and relevant times, and use YouTube Help for errors shown in Live Control Room. Ask your ISP about recurring outbound test failures. Sharing the evidence from each layer lets the relevant support team investigate its part of the route instead of asking you to restart everything without a diagnosis.
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 “Not receiving video” mean YouTube is offline?
No. It means Switchboard’s confidence monitor is not seeing video from the encoder, so investigate the incoming connection first. It does not establish what YouTube is receiving or whether YouTube itself is having a problem.
Should I replace the Switchboard key with my YouTube stream key?
No. They serve different connections: the workflow URL and key are for encoder ingest to Switchboard, while YouTube’s key is for the YouTube connection. Update only the credential identified by the relevant status or error.
What should I do if Switchboard receives video but YouTube still shows an error?
Check the health indicator and timestamped message in YouTube Live Control Room, then address the specific property or credential it identifies. Keep Switchboard’s receiving status and the encoder log so you can compare what was happening at the error time.
Will switching to SRT stop the reconnects?
Not necessarily. Switchboard describes SRT as useful for low-latency streaming on unstable networks, but compatibility and the fault itself matter. Treat a protocol change as a controlled test after the basic route, credentials, encoder and connection checks.