Cron can start FFmpeg on a VPS at a planned time, sending a prerecorded file to a YouTube Live event as an encoder feed. It does not schedule or publish the event for you: YouTube Studio may still require you to review the preview and click Go live.
Treat this as two coordinated jobs: prepare the event in YouTube Studio, then arrange for the encoder process to connect at the right time. The command and cron patterns below are examples to adapt and test on your distribution and FFmpeg build, not a turnkey script.
What cron can and cannot automate
Cron is a scheduler for commands. At the time specified in its configuration, it can invoke a script that starts FFmpeg, which reads your media file and sends audio and video to the event's ingest address using its stream key. If the process runs as expected, YouTube can receive the encoder feed.
That is not the same as creating an event, setting its privacy, or publishing it. A scheduled event has its own state in YouTube Studio. YouTube's documented encoder workflow includes starting the encoder, waiting for its preview in Live Control Room, and clicking Go live. A cron entry cannot perform that Studio action by itself.
Think of the hand-off this way: Studio provides the destination and event; cron starts the local process; FFmpeg sends the feed; you confirm the event's state. A process listed as active on the VPS is evidence only that a process exists, not that the event is public or even receiving usable audio and video.
Cron suits a one-off launch time on a Linux machine that is already available. It does not, on its own, supervise a broadcast intelligently, distinguish an intentional end from a failure, or maintain YouTube API credentials and broadcast state. If you need a continuous rotation of files rather than one file per event, compare the workflow in guidance on streaming multiple videos continuously.
Prepare the YouTube Live event first
Before configuring the VPS, confirm that your channel can go live. YouTube says first-time live streaming enablement may take up to 24 hours, so enabling it at the last minute can derail a planned launch. Check the current YouTube Help instructions for live streaming and allow time for channel eligibility and activation.
In YouTube Studio, create or schedule a live event. Select visibility and the other event settings there. Scheduling is distinct from starting an encoder: it creates the event and can provide a watch page for sharing and reminders, but it does not make a feed appear before the encoder connects. Follow YouTube's current instructions for scheduling an encoder stream.
Open the event's stream settings and note the ingest URL and stream key. The key is the credential that lets the encoder connect to the event, so treat it like a password. Do not put it in a public repository, a screenshot, a shared command history, or a cron line that other users can inspect. Store it in a file with restricted permissions or another protected configuration source available to the account that runs FFmpeg.
Do not assume that a previously saved key or URL is the right pair for every event. Use the details shown for the event you are preparing, and check the URL form in Studio rather than copying an example from a forum. If the key is exposed, replace it in YouTube Studio and update the protected configuration.
Use a private or unlisted test event before relying on an unattended launch. A test should cover more than whether a process starts: check the actual video, audio, aspect ratio, preview, and the event's Go live state. A channel that has not streamed from this VPS before may reveal file, codec, firewall, or permission problems only when the feed is connected.
Configure FFmpeg and the media file
Install or make available an FFmpeg build for the VPS operating system, then identify its absolute path and the media file's absolute path. Check that the file is readable by the account that will run the cron job. The job's environment is not necessarily the same as your interactive shell, so relying on a command found only through a customised PATH is fragile.
A conceptual command shape is:
/usr/bin/ffmpeg -nostdin -re -i /absolute/path/video.mp4 \\
-c:v libx264 -c:a aac \\
-f flv 'rtmps://INGEST_URL/STREAM_KEY'
This is a pattern, not a verified command for every FFmpeg build, file, or YouTube endpoint. Replace the placeholder destination with the exact event details from Studio, and select output and encoding options that work with the source and current YouTube guidance. Avoid placing a real key in a script committed to source control or in a command example that may be retained in shell history.
The -re input option reads the file at its native frame rate; FFmpeg documents it as equivalent to -readrate 1. Without real-time pacing, a file can be read faster than its playback duration, which is not what you want for a live feed. Input options belong before the input they affect. Verify the syntax against the installed release and its FFmpeg documentation.
YouTube recommends RTMPS, the secure extension of RTMP. Its published encoder settings cover supported codecs and other output choices. The guidance includes H.264, H.265/HEVC or AV1 options depending on configuration, frame rates up to 60 fps, a recommended two-second keyframe interval with a four-second maximum, AAC or MP3 audio, and constant bitrate encoding. Use the current settings table for your chosen resolution and configuration rather than borrowing a bitrate from an unrelated example.
There are two broad ways to handle the file. Stream-copying avoids re-encoding, but only works if the existing streams, timestamps, frame rate and container are suitable for the event. Transcoding lets you choose output properties to fit the current ingest guidance, but requires CPU capacity. Check the source first and test the selected settings; there is no universal VPS size that fits every file and encoding plan.
For a one-time broadcast, omit looping options so the input reaches its end. To repeat a file intentionally, FFmpeg documents -stream_loop -1 for infinite input looping. For example, put it before the input option: -stream_loop -1 -re -i /absolute/path/video.mp4. This changes the editorial behaviour of the broadcast; it is not a fix for an incorrectly configured event. If you need a sequence of distinct clips, the FFmpeg playlist approach is more relevant than looping one MP4.
Schedule the encoder process with cron
Put the command in a script rather than embedding a long command and credentials directly in the crontab. The script can set a deliberate working directory, refer to absolute paths, load protected settings, and direct output to a log. Keep the configuration readable only by the account that needs it, and confirm the script is executable by that account.
A script might have this general shape:
#./bin/sh
set -eu
cd /srv/live-event
exec /usr/bin/ffmpeg -nostdin -re -i /srv/live-event/video.mp4 \\
[your tested output and encoding options] \\
-f flv "$INGEST_URL/$STREAM_KEY"
The bracketed text is a reminder to supply tested options, not literal FFmpeg syntax. Arrange for the environment variables to be provided securely to the script; do not assume cron inherits them from your login shell. An alternative is a protected configuration file sourced by the script, provided its permissions and shell syntax are correct. Never print the destination containing the actual key as part of routine diagnostics.
A crontab entry conceptually has a schedule followed by an absolute script path and a log redirection, for example:
30 18 * * * /srv/live-event/start-stream.sh >> /var/log/live-event/encoder.log 2>&1
This example means a scheduled invocation according to the machine's cron time zone and syntax; it is not universally portable. Check the crontab format, time zone, and cron service behaviour for your VPS operating system or provider. Confirm what local time the machine uses, especially if your event is advertised in Indian Standard Time but the VPS clock or settings use another zone.
Cron's environment is commonly more limited than an interactive login. Test the script as the same system account and with a similarly sparse environment before relying on the schedule. Use the absolute FFmpeg path, set a working directory, and make log destinations explicit. Do not put secrets in the schedule line itself.
Prevent accidental overlap. If a prior run is still active when another scheduled invocation begins, you could send duplicate feeds or create confusing process state. A lock mechanism or a carefully managed service can help, but its exact implementation depends on the operating system and how you want to handle a missed or repeated launch. Test that behaviour rather than assuming cron will deduplicate jobs.
Cron can initiate a planned run, while a service manager or supervisor is a separate tool for ongoing process supervision. Choose based on the failure behaviour you need: restarting after a transient drop may be useful, but an indiscriminate restart can also turn a planned end into an unintended continuous broadcast. The article on running a long video on repeat discusses the distinct playback decision; process scheduling should not decide that editorial question for you.
Check preview and complete Go live
When the schedule fires, inspect both sides of the connection. On the VPS, check whether the expected FFmpeg process started and whether its log reports a connection or input error. In Live Control Room, wait for YouTube to show the encoder preview. Check that the picture is correct, the audio is present and intelligible, and the stream is connected to the intended event.
Then complete the YouTube Studio action required for that event: click Go live when the preview is ready if the workflow prompts for it. Do not tell viewers that the stream is live solely because cron ran or FFmpeg is still running. Verify the public event state from the viewer-facing page as well as Studio.
For an event advertised in advance, make the scheduled start time and your encoder launch time work together. Launching too early can leave an encoder feed waiting before the event is due; launching too late can leave the event without a preview when viewers arrive. Use a test event to learn how the current Studio workflow presents the preview and any required publishing action. The scheduled stream may have a watch page before the public feed is live, so distinguish the event page from a live broadcast.
Handle logs, failures, and repeat runs
Logs help you separate common failure classes. A missing input file or permission error points to the VPS script or account. A connection error can point to the network, ingest URL, or key. A connected feed with no usable picture or sound points to media streams or encoder settings. Compare the timestamp and message in the log with what Studio displays, without copying the secret destination into a broadly accessible log.
Plan log retention and rotation so that an unattended process does not fill the disk. Also check available disk space, outbound bandwidth or egress limits, CPU use if transcoding, and whether the source file remains available for the entire event. These are operational checks, not a promise that any particular VPS specification will handle your media. Resource needs differ with file resolution, codec, bitrate, and whether you re-encode.
Test the whole lifecycle: the scheduled launch, preview, Go live action, normal file completion, and any planned loop. YouTube says streams under 12 hours are automatically archived; check the current event and archive state in Studio rather than assuming the same behaviour for a longer broadcast. Stopping the encoder ends the feed, but inspect the finished stream and replay before treating the task as complete.
Use an explicit decision for failure recovery. If the connection drops, decide whether a person should inspect the event, whether a separate supervisor should restart FFmpeg, or whether the event should end. Do not make a retry loop that runs forever without checking the event state: after a planned end, it could reconnect and create an unwanted feed. Keep the recovery procedure understandable to whoever is on call, even if that is you.
For repeat playback, choose deliberately between a one-shot file and infinite looping. A one-shot feed naturally finishes when the input ends; -stream_loop -1 keeps the same input repeating until the process is stopped or fails. The latter can be appropriate for an always-on ambience station, but it changes the broadcast from a finite event to an ongoing one and needs a clear stopping and monitoring plan.
When API automation is a separate project
YouTube's Live Streaming API offers programmatic management of broadcasts and streams. That is a different implementation from cron launching FFmpeg. Cron could, in principle, launch code that calls an API, but the scheduler does not supply the API authentication, create the desired broadcast state, bind the event to a stream, or handle the state transitions and errors for you. Start with the YouTube Live Streaming API documentation if you are building that system.
An API-managed workflow needs its own decisions about account authorisation, credentials, permissions, retries, and what to do when YouTube returns a state your code did not expect. It also needs testing against the current API and channel setup. Keep this separate from a simple cron task that starts a known encoder feed for an event you have already prepared in Studio.
For a small channel with one scheduled prerecorded event, Studio plus a tested FFmpeg script may be simpler because you can see and perform the publishing step. If you need to create and manage many events programmatically, API work may be justified, but it adds software and credential maintenance. Neither path removes the need to verify what viewers can see.
A VPS-based workflow also means you own its operating system, job configuration, file availability and recovery process. If the recurring burden is keeping a computer on and checking whether an encoder has stopped, StreamNeo removes that particular computer-and-restart task: it turns an uploaded video into a YouTube stream while your computer is off. It remains a YouTube-only route, and it does not change the need to prepare the event and confirm YouTube's live state.
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
Can cron make a scheduled YouTube stream go live automatically?
Cron can start an encoder process at a planned time, but it does not itself click Go live in YouTube Studio. YouTube's documented scheduled encoder workflow calls for waiting for the preview and completing the Go live step when required. Verify the event state in Studio and on its viewer-facing page.
How do I loop one MP4 with FFmpeg?
FFmpeg documents -stream_loop -1 for infinite input looping; place it before the input it applies to, for example -stream_loop -1 -re -i /absolute/path/video.mp4. Adapt the rest of the command to the file and current YouTube settings, and test it with an unlisted or private event. A loop also needs an intentional stopping plan.
Why does the event show an encoder preview but not appear live?
An encoder preview means YouTube is receiving a feed, not necessarily that the scheduled event has been published. Check the event state and follow the current Live Control Room workflow, including the Go live action when prompted. Confirm from the public watch page before telling viewers the broadcast has started.
Does the VPS need to stay on for the stream?
For a cron-and-FFmpeg setup, the VPS must be available to run the process and send the feed for the duration of the broadcast. If it stops, loses its network connection, or cannot read the media file, the feed can be interrupted. Plan monitoring and recovery for the VPS you choose.