A scheduled YouTube playlist rotation needs two separate parts: a script that decides what to change through the YouTube Data API, and cron to run that script at a chosen time. Cron does not understand playlists, and YouTube does not provide a built-in “rotate” operation.
Before you schedule anything, decide what rotation means for your channel. You might move an existing item to a new position, cycle a set of videos, or remove old items and add new ones; those choices have different effects and API calls.
Define the rotation you want
Write down the intended result before choosing an API method. For example, a devotional channel might want a fixed set of bhajans in a different order each morning. A local news loop might instead remove yesterday’s bulletin and add today’s, while leaving the rest of the list untouched. These are different policies, even though both might be described as “rotation”.
Clarify the starting state, the desired ending state, and what should happen when an item is missing or already present. Decide whether the list has a fixed membership, whether it may contain duplicate videos, and whether the rotation should affect every item or only a named subset. This makes it possible to write a predictable script rather than a sequence of guesses.
Also consider what viewers will experience. A playlist change is not the same thing as changing a live broadcast’s current media or guaranteeing that a live player follows the new order immediately. If your goal is to keep a prerecorded video playing around the clock, the playback and broadcast setup is a separate concern; see this guide to streaming a church choir playlist around the clock.
A useful policy statement is specific enough to test. For instance: “At 08:15 each day, move the oldest item in this set to the end, but do nothing if the list is empty.” You can then identify the item to move, the API operation that can implement it, and the expected state after a successful run. Avoid an underspecified goal such as “shuffle the playlist” unless you have also defined whether the shuffle should be repeatable and how duplicates are treated.
What cron does—and does not do
Cron is a scheduler on Ubuntu. It checks crontab entries and starts their commands according to the schedule. It runs a command under the account that owns the crontab; it does not log in to YouTube, select playlist items, or decide what “next” means. The Ubuntu crontab manual documents the schedule fields and the user context.
That division of responsibility matters when the job fails. Cron can start a command at the intended time, but your script must handle API authentication, retrieve playlist state, apply your policy, and report errors. If the script has a bug, cron will faithfully run the buggy command again on the next scheduled occasion.
A cron schedule has five time fields—minute, hour, day of month, month, and day of week—followed by the command. The example later in this article uses a daily schedule and a local file path, but you must substitute paths and a time that fit the Ubuntu account and machine you actually use.
Cron also runs with a deliberately limited, non-interactive environment. Do not assume it will inherit the PATH, current directory, shell startup settings, or credentials that are available in a terminal window. Use absolute paths and explicitly set only the environment your script needs. The Ubuntu manual describes environment defaults and the effect of cron timezone settings; check the manual for the Ubuntu release installed on your machine before relying on a timezone directive.
If the Ubuntu machine is not available at the scheduled time, cron may not provide the catch-up behaviour you expect. Treat a missed run as a separate policy question: is it safe to run later, should the script skip it, or must you review the playlist manually? If you need a schedule tied to a particular release, event or live programme, do not assume that a basic recurring cron entry covers those requirements.
Choose the YouTube Data API operation
The YouTube Data API has playlist methods and playlist-item methods. The playlist-item methods let an authorised client list entries and insert, update or delete them; you compose those operations into your own rotation policy. The playlist item reference is a useful starting point for inspecting the fields returned by a list request.
For a rotation that changes an existing item’s position, examine the update method and its documented request body. Reordering an existing entry is conceptually different from deleting it and inserting it again. If you remove and re-add, you may change membership or create a duplicate if your script does not first check the current list. For a policy that replaces an item, deletion and insertion may be appropriate, but only after you have explicitly decided what should be removed and what should be added.
An item in a playlist has its own playlist-item ID, separate from the video ID. When deleting, use the playlist-item ID returned by the API, not merely the video’s ID. This distinction is important if the same video appears more than once: identifying the video alone does not necessarily identify which playlist entry you intend to remove. The delete method documentation describes the ID parameter and authorised request requirement.
A read-before-write flow makes the policy easier to reason about. First list the relevant items, then derive the intended action from the current state, then perform only the required update, insertion, or deletion. If the current playlist already matches the desired state, the script can report that there is nothing to do rather than making a needless write. Keep the policy conservative when the data is unexpected: an empty list, an unfamiliar item, or a failed list request should not automatically trigger a destructive change.
API calls also consume quota. Google’s current documentation should be checked for the project’s allocation and the latest method costs; the YouTube Data API overview explains project setup and quota. Research notes for this article report that list calls cost one unit, while insert and delete calls cost 50 units each, and that the default combined allocation for most endpoints is 10,000 units per day. These are documented defaults, not a guarantee for every project: verify the current quota information for your own project, and avoid unnecessary writes.
Authorise playlist changes with OAuth
Playlist writes require OAuth authorisation with an applicable scope. A plain API key can identify a project for some public-data requests, but it does not authorise changes to a user’s playlist. The Google API getting-started guide covers enabling the API and OAuth setup; consult the current official instructions for the client library and credentials flow you choose.
The account that grants permission needs access to the playlist you intend to edit. Take care to select the correct Google account during authorisation, particularly if you manage a personal channel and a brand account. A successful token creation for one account does not prove that it can update a playlist owned or managed under another channel identity.
A scheduled process has no person present to click through an interactive consent window. Use a Google-supported client library and follow its current authentication guidance for storing credentials and refreshing access. Do not assume that copying a token file from a laptop will keep working indefinitely. Before scheduling, verify that the chosen flow can refresh credentials as required and that the script reports an expired or revoked authorisation clearly.
Protect credential files from other local users. Keep them out of public repositories, shared folders, and logs; restrict file access to the Ubuntu account that needs them. If you revoke access, change accounts, or rotate credentials, rerun the authorisation process as the job’s intended user and test the result before the next scheduled change.
Write and test the rotation script
Keep the script’s responsibilities small and visible: load its configuration, authorise, list the playlist items it needs to inspect, calculate the planned change, apply it, and record the result. Use the client library’s documented methods rather than assembling requests from memory. The official insert reference describes an authorised operation that adds a resource to a playlist; it does not define a general rotation policy for you.
Separate the decision from the write where practical. A dry-run mode can print the planned action—such as which playlist-item ID would move or be removed—without changing YouTube. Review that output against the playlist in YouTube Studio or the relevant account before enabling writes. A script should avoid deleting an entry merely because an API response was incomplete or a lookup returned no result; report the unexpected state and stop instead.
Test in stages. First run the program from a terminal under the same Ubuntu account that will own the crontab. Confirm that it can find its configuration and credential files, reach the API, list the intended playlist, and produce the expected plan. Then test the write behaviour on a low-risk playlist or with a reversible change that you understand. Do not call an example below tested code: it is a schedule template only, and the language-specific OAuth lifecycle depends on the library and its current version.
Make repeat runs safe. Cron can start another run while a previous one is still active if a request hangs or the job takes longer than expected. Consider a lock or another single-run guard, and have the script detect whether the desired result is already in place. If a write succeeds but the process loses its connection before recording success, the next run should inspect actual playlist state rather than blindly repeating a potentially duplicative insert.
Playlist management and live playback should also be tested separately. An API write changes playlist data; it does not replace the encoder, stream key, or broadcast loop that delivers video to viewers. If you are setting up a file-based broadcast as well, this VLC live-stream loop guide covers a different part of the workflow. Keep stream credentials out of command history and logs, as explained in this guide to protecting a YouTube stream key from FFmpeg history.
Schedule it in the intended Ubuntu user’s crontab
Edit the crontab for the account that should run the job, using crontab -e while logged in as that user. Do not use sudo crontab -e unless the job genuinely needs to run as root: root’s crontab is separate and can have a different home directory, credentials, and file permissions. The account needs permission to read its configuration and credentials and write to the chosen log location.
A daily example is:
# minute hour day-of-month month day-of-week command
15 8 * * * /usr/bin/python3 /home/ubuntu/bin/rotate_playlist.py >> /home/ubuntu/logs/rotate_playlist.log 2>&1
This is a template, not tested code. Replace ubuntu, the interpreter, the script path, and the log path with values from your machine. The log directory must already exist and be writable by the crontab owner. The redirection appends both normal output and errors to the same file so that a failed run has somewhere to report what happened.
The schedule above uses the machine’s applicable cron schedule timezone; it should not be read as a promise that 08:15 means a particular local time everywhere. If the playlist change needs to happen at a particular timezone, check the manual for your Ubuntu release and cron package before using CRON_TZ. Ubuntu manuals distinguish schedule timezone settings from TZ in the command environment. When in doubt, confirm the actual run time with a harmless test entry and the system clock.
Cron’s limited environment can be made explicit in the crontab where necessary. Prefer absolute paths for the interpreter and files. If your program requires environment variables, define only the needed values in a secure, appropriate way; avoid placing secrets directly in a world-readable file or a command line that may be exposed to other users. A configuration file with restrictive permissions is usually easier to audit than relying on settings from an interactive shell.
Save the entry, then inspect the installed crontab with crontab -l as the same account. Check the five time fields carefully: a field in the wrong position can turn a daily job into a different schedule. For details of editing and interpreting entries, the Ubuntu cron help page supplements the manual.
Check logs, timing, and failure behaviour
Run the script directly first, then wait for a scheduled invocation and inspect its log. A useful log entry states when the run began, which playlist or non-secret identifier it acted on, whether it made a change or found the desired state already present, and any API error. Do not log access tokens, client secrets, or other credentials while diagnosing an OAuth problem.
If the expected log entry does not appear, check that the crontab belongs to the intended account, the schedule fields are correct, and the script and log paths exist with appropriate permissions. Then inspect the system cron log or journal for the Ubuntu release in use. Cron output may be mailed on some systems depending on local mail configuration; file redirection gives you a direct place to look, but it does not replace checking system logs when cron itself may not have started the command.
Plan for API errors and network interruptions. A transient failure should be recorded and should not leave the script assuming that a write succeeded. If the write result is uncertain, the next run should read the playlist again and compare it with the desired state before trying again. An OAuth failure, quota response, missing playlist, or unexpected item layout should produce a clear message and stop rather than trigger a chain of speculative changes.
Choose a schedule interval that suits the policy, not the fastest interval cron permits. A daily playlist rotation does not need repeated calls through the day. Fewer unnecessary reads and writes make the job easier to inspect and reduce quota use. If the timing is important to a live audience, check the playlist and broadcast manually after the first scheduled change; the cron log confirms command execution, not what viewers saw in a player.
Do not rely on @reboot to mean “run after the network and authorisation dependencies are ready”. Startup ordering varies, and cron may start a command before services the script needs are available. If you use a reboot-triggered job, build explicit readiness and retry behaviour into the job and verify it on the target Ubuntu version. For processes whose lifecycle and restart behaviour need system-level management, this guide to restarting an FFmpeg stream after a VPS reboot with systemd concerns stream processes rather than playlist API changes.
Cron is a good fit when the Ubuntu host is already on and the task is a simple recurring command. It is not an always-on host, a missed-run recovery system, or a playlist-management feature. If the actual problem is keeping a video broadcast running while your own computer is off, StreamNeo addresses that separate operational burden by running an uploaded file as a YouTube live stream; it does not automate playlist rotation or replace the OAuth work described here.
If this rotation is important to a channel, keep a short operating note beside the script: the playlist identity, what the policy changes, which account authorises it, where logs are stored, and how to disable the crontab entry. That gives you a calm recovery path if the account changes or an API response differs from what you expected. It also helps distinguish a scheduled playlist change from a problem in the separate live-stream setup.
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 YouTube have a playlist rotation scheduler?
No. YouTube’s playlist-item API provides methods to list and change entries, but you define the rotation policy in your own script. Cron can schedule that script; it does not provide a YouTube-specific scheduler.
Can I use an API key to change a playlist?
No. Playlist writes require OAuth authorisation with an applicable scope and an account that has access to the playlist. An API key alone does not authorise an insert, update, or delete.
What ID should a delete request use?
Use the playlist-item ID returned by the API, not just the video ID. The playlist-item ID identifies the entry in the playlist, which matters when the same video can appear more than once.
Will cron run a missed job when Ubuntu comes back online?
Do not assume so. A basic cron entry is a schedule, not a guarantee of catch-up after downtime; decide whether a late rotation is safe and handle that policy in the script or operational process.