If your YouTube 24/7 stream goes offline when you disconnect from SSH, first find out what actually stopped: the SSH connection, the encoder, the VPS itself, or YouTube ingest. A terminal disconnect alone does not prove the encoder stopped, and neither tmux nor systemd can keep a provider-suspended VM running.
“Idle session suspension” is ambiguous: it might describe an ended shell, a stopped virtual machine, or a provider policy. Check YouTube Studio and the VPS before changing settings; then use tmux for an SSH-only disconnect, systemd for process recovery or boot startup, and your provider’s policy or support channel if the VM is stopped.
What “idle session” might mean
There is no provider-neutral technical event called “idle session suspension” that tells you exactly what failed. A dashboard or support reply might use that phrase for an SSH session that timed out, a shell that was terminated, an encoder that exited, or a virtual machine paused or stopped under the provider’s rules. Without the provider’s name, plan, notice and event time, you cannot safely infer which one happened.
The distinction matters because these failures live at different layers. SSH is the remote terminal connection between your computer and the VPS. The encoder, such as FFmpeg, is a process running on the VPS. The VM is the machine hosting that process. YouTube is a separate destination receiving the video feed. A remedy at one layer does not fix a failure at another.
For example, if your laptop sleeps and SSH disconnects, the VPS may continue running. If FFmpeg crashes while SSH remains connected, a terminal multiplexer will not restart it. If the provider stops the VM, there is no running machine for a process supervisor to manage. If FFmpeg remains alive but YouTube reports an unhealthy feed, investigate the encoder output and outbound connection instead.
Record the time the stream went offline before taking action. That gives you a point to compare against YouTube Studio, process logs and provider notices. Avoid immediately changing the stream key or encoder settings: those changes can obscure the original evidence, and a key change will not revive a stopped VM.
Check the stream and the VPS first
Start with YouTube Studio’s Live Control Room and open the stream that went offline. Check its health indicator and any specific error message. YouTube’s live streaming troubleshooting guidance covers encoder and connection issues; follow the error shown for your stream rather than applying every suggested setting at once.
Next, check whether the VPS is available in the provider’s control panel or console. If it is reachable, inspect whether the encoder process still exists and whether the machine has recently rebooted. If the VM is unavailable, look for a suspension or stop notice in the provider dashboard, email, or support history. Do not rely on the SSH client’s “connection closed” message to tell you whether the VM itself is alive.
A useful first pass is:
| What you find | What it suggests | What to check next |
|---|---|---|
| SSH closed, VPS still running, encoder still present | Terminal connection may have ended independently | Reconnect and inspect the existing session and Studio health |
| VPS running, encoder process absent | Encoder exited or was stopped | Review logs and consider systemd supervision |
| VPS recently rebooted, encoder absent | Process did not start again at boot | Check service enablement and boot logs |
| VPS stopped or suspended in provider console | Provider-side VM action is possible | Read the notice and ask the provider for the reason |
| Encoder present, Studio reports unhealthy or offline | Ingest, output format, or network may be at fault | Review Studio’s exact error, encoder output and outbound connectivity |
These clues are not proof on their own. A process can exist while producing invalid output, and a displayed VM state can lag behind an event. Use the logs and provider’s event records to confirm. If you need help from support, provide the event time, VM state, relevant service logs and the exact notice, while keeping credentials private.
If only SSH disconnects, keep the encoder in tmux
When the VPS remains up and the encoder is still running, an ordinary shell launched over SSH may not be a dependable place to leave a long-running job. Depending on how the process was started and the shell’s behaviour, it can receive a hangup or stop when the session ends. A remote tmux session gives the process a terminal session that is independent of the SSH connection.
The tmux manual describes a session as surviving accidental disconnection, including an SSH timeout, and intentional detaching. In practice, create the session on the VPS, start the encoder inside it, then detach from tmux before closing SSH. Reconnect later and attach to that same session to inspect the terminal output.
For example, on the VPS you can create a named session with tmux new -s youtube. Start your encoder command inside that session. To detach without stopping it, press Ctrl-b, release the keys, then press d. After reconnecting, tmux ls lists available sessions; tmux attach -t youtube reconnects to the named session if it still exists.
This is a practical fix for the specific case where SSH ends but the VPS and tmux server remain alive. It is not a restart policy. If FFmpeg exits, the session may remain open with the shell prompt visible, but the stream is no longer being encoded. If the VPS reboots, its tmux session is gone. If a provider stops the VM, tmux cannot keep it online.
Keep a note of how you started the process and how to reattach. A second operator should be able to see whether FFmpeg is running without guessing which terminal or session contains it. For a playlist or looping setup, make sure the media path and command are correct on the VPS; this FFmpeg and Nginx RTMP looping guide covers a related playback workflow, not SSH persistence itself.
Use systemd for process recovery or reboot
If the encoder exits unexpectedly, or must start again after a reboot, systemd is usually a better fit than relying on an interactive terminal. A system service is managed outside your login shell and can be configured to start at boot and restart after qualifying failures. It also gives you a consistent place to inspect service state and logs.
The systemd service manual documents restart settings, including Restart=on-failure. That setting can restart a service after conditions such as a non-zero exit or certain failures, subject to systemd’s rules and configuration. It does not mean “restart under every circumstance”: a deliberate stop, administrative action or provider-side VM suspension is a different event.
A service needs an accurate executable path, working directory, permissions and environment. Test the encoder command manually before moving it into a service, then make sure the service runs with access to the media files and any required configuration. Protect the YouTube stream key as a credential. Do not put it in a public script, repository, screenshot or support ticket; if it is exposed, rotate it in YouTube Studio.
For reboot recovery, enable the service at boot and test the behaviour during a planned maintenance window. For process recovery, decide whether a restart makes sense for the failure modes you observe. A service that repeatedly fails because the file is missing, the key is invalid, or the network is unavailable can enter a cycle of failures; automatic retries do not correct the underlying cause. Read the service logs and fix the actual error.
YouTube’s encoder workflow uses a server URL and stream key, but a running service is not evidence that YouTube is receiving a healthy stream. After starting or recovering the encoder, return to Live Control Room and check the incoming preview, health and any error details. For output problems, consult the relevant YouTube streaming error guidance, which discusses such matters as encoding format, bitrate and keyframes. Change only settings relevant to the error you see.
Separate encoder trouble from ingest trouble
A process can remain present while its output is stalled, malformed or unable to reach YouTube. Conversely, Studio can report an unhealthy feed even though the encoder process has not exited. That is why checking only ps output or a green service state is not enough to call the stream healthy.
Compare the time of the Studio error with the encoder’s output and service logs. Check whether the encoder reports an input-file error, reconnect attempts, an authentication problem, or a failure writing the stream. Then check the VPS’s outbound connectivity and any provider limits that apply to network transfer. If the connection itself is problematic, the provider or network operator may need to investigate it; tmux and systemd are not network repairs.
If your channel sends a long prerecorded programme, distinguish a reliable live feed from the replay archive. YouTube Help says streams under 12 hours are automatically archived; do not assume a longer uninterrupted stream will be archived. If a replay matters, keep a separate recording or schedule shorter sessions where that suits the channel. For a devotional playlist, this guide to preventing audio gaps between songs addresses a different part of the viewer experience: continuous audio between items.
Check the provider’s policy and notices
If the provider console says the VM was suspended or stopped, read the specific notice and the current terms for your plan. Look for language on continuous workloads, idle use, resource consumption, acceptable use, outbound transfer and administrative suspension. Do not assume an “idle” label means the same thing across providers or plans.
Ask support a narrow question: was the virtual machine stopped, was only the SSH connection or shell ended, or did a resource or policy rule act on the instance? Include the timestamp and instance identifier, but never send the stream key. Ask what condition caused the action and what the provider permits for a continuous YouTube encoder workload. Save the reply alongside the event record.
A provider might stop a VM for a reason unrelated to SSH, while an SSH session can time out without any VM action at all. Likewise, a keepalive setting can sometimes help a network connection remain open, but it does not grant permission for a workload or override a provider’s suspension decision. Do not use repeated reconnects or artificial activity as a substitute for understanding the policy.
If you are comparing plans, verify their current terms directly and ask about the workload you intend to run. Consider continuous-use permission, restart and boot behaviour, outbound data terms, logs, monitoring, regional location if it matters to your audience, and total cost. Vendor limits and prices change, so do not rely on an old forum post for a plan specification.
Move hosts if the provider stops the VM
If the provider confirms that it stops the VM because continuous encoding is not permitted, changing tmux or systemd settings is not the remedy. Choose a hosting arrangement whose published terms allow the workload, or use a managed service suited to continuous prerecorded YouTube streams. Confirm the service’s present capabilities, regional availability, terms and costs before moving; do not select a host based on an unverified claim that it will never stop.
When comparing another VPS or managed option, look at the operational work as well as the headline plan. Can you inspect failures? Does the service restart after an encoder error or machine reboot? Are outbound transfer and long-running processes permitted? Can you store and update the source file safely? Does the option fit the stream format and channel workflow? These are questions to confirm with the vendor, not assumptions to make from its marketing description.
If you move, prepare a controlled change rather than cutting over blindly. Keep a copy of the source video and encoder configuration, protect the stream key, and test the output in YouTube Studio. Check the stream health and audio before leaving it unattended. If you loop a series of items, ensure the transitions and playback order are correct; this article on automating a Tamil devotional playlist on YouTube Live may help with the content workflow, but it does not replace checking the new host’s policies.
For some operators, avoiding VPS administration is itself the point. StreamNeo can remove the need to keep your own computer and an SSH terminal in the loop by taking an uploaded video and running it as a YouTube live stream; it is YouTube-only, so check that this matches your channel’s workflow. Whatever option you choose, verify its current terms and test the stream rather than treating a successful upload or a running process as proof of delivery.
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 YouTube 24/7 stream go offline when I disconnect from SSH?
It may not: an SSH disconnect can happen while the VPS and encoder continue running. Reconnect, check the VPS state and process, and inspect the matching Live Control Room entry before choosing a fix. If only the terminal connection is the issue, run the encoder inside a remote tmux session and detach.
How do I keep FFmpeg running after I close my VPS terminal?
For a terminal-only disconnect, start FFmpeg inside tmux on the VPS and detach before closing SSH. If you need recovery after FFmpeg exits or a reboot, configure a systemd service and test its restart and boot behaviour. Neither tool can keep a provider-stopped VM online.
Can tmux or systemd prevent an Indian VPS provider from suspending the machine?
No. tmux preserves a session across certain terminal disconnects, while systemd supervises a service on a running machine. If the provider stops or suspends the VM, check the notice and terms with that provider, then move to an option that permits your continuous workload if necessary.
What should I check if FFmpeg is running but YouTube says the stream is unhealthy?
Read the exact Live Control Room error and compare its timestamp with encoder and service logs. Check the stream output, key, format and outbound connection as indicated by that error. A running process alone does not show that YouTube is receiving a healthy feed.