Guides

    Cron Schedules for Recurring Content Series

    Post every Tuesday has to become five specific fields somewhere. The cron syntax, four everyday translations, and two prerequisites that fail silently.

    Versely Team7 min read

    "Just run it every Tuesday morning" is a perfectly reasonable sentence to say out loud and a genuinely underspecified one to hand to a machine. A computer scheduling a recurring job doesn't work from a vibe — it works from five specific fields, in a specific order, and "Tuesday morning" has to become exactly those five fields somewhere between the request and the thing that actually runs. Get the translation right and a series posts itself for months without another thought. Get one field wrong, or skip a setup step the schedule quietly depends on, and it either runs at the wrong time or doesn't run the way you expected at all.

    The five fields, plainly

    Standard cron syntax is five space-separated fields, always in this order: minute, hour, day-of-month, month, day-of-week. An asterisk in any position means "any value here" — no constraint. So 0 10 * * * reads, field by field, as: minute 0, hour 10, any day of the month, any month, any day of the week. Put together, that's "at 10:00, every day" — the exact expression Versely's scheduling tools use as their own example for a daily-10am cadence.

    Day-of-week uses 0 through 6 (or 1 through 5 for the common weekday shorthand), with 0 or 7 as Sunday and the rest counting forward — so 1 is Monday, 3 is Wednesday, 5 is Friday. That numbering is the key to reading or writing almost any weekday-specific schedule once you have it.

    Four everyday cadences, translated

    A handful of phrasings cover most recurring content series, and knowing the pattern means you can extend it to whatever cadence you actually need:

    1. Every day, fixed time. "Every day at 10am" becomes 0 10 * * * — every field pinned except day-of-month, month, and day-of-week, which stay wide open.
    2. Specific weekdays. "Monday, Wednesday, Friday at 10am" becomes 0 10 * * 1,3,5 — the day-of-week field takes a comma-separated list instead of a single value or a wildcard.
    3. Every N days. "Every 2 days at 10am" becomes 0 10 */2 * * — the */N step syntax in the day-of-month field means "every Nth day," counting from the schedule's start.
    4. Once a week, a single day. Applying the same day-of-week numbering to a single value rather than a list gives you a weekly cadence — "every Monday at 9am" becomes 0 9 * * 1.

    One detail changes all four if you skip it: these times are UTC unless you specify otherwise. Versely's scheduling tools are explicit that they'll ask for your preferred local time when it's unclear, and treat an unspecified time as UTC by default — so 0 10 * * * means 10:00 UTC, not 10am wherever you happen to be sitting, unless that conversion already happened before the expression got written.

    The two prerequisites that fail silently

    Neither of these stops you from calling a scheduling tool. Both determine whether what happens next is actually what you wanted.

    The workflow has to already be built before it can be scheduled. Versely's recurring-series scheduler requires the target workflow to already have a saved scenes array and asset map in place — the creative content has to exist and be saved first, and the cron expression attaches a cadence to something real rather than to an empty idea. Trying to schedule a workflow that hasn't been saved with scenes yet is the single most common way a "why isn't my series running" question turns out to have a one-word answer: it was never actually finished.

    Auto-posting needs connected accounts before the schedule starts, not after. If a recurring series is meant to post its output automatically, the platforms it's posting to need to already be connected accounts, not accounts you're planning to connect later. A schedule set up before that connection exists will still generate on cadence — the video or slideshow gets made — but nothing will actually reach the platform, because there's nowhere connected for it to go yet. Checking connections before scheduling, not after the first run quietly does nothing publicly visible, is the difference between a series that works from day one and one that generates into a void for a week before anyone notices.

    Three different things that all sound like "scheduling"

    "Recurring content series" gets used loosely enough that it's worth being precise about which mechanism actually applies. A recurring video series runs on schedule_workflow — a saved workflow, a cron expression, and on each tick, a fresh script generated around the same characters and style. A recurring slideshow series is a related but separate tool built the same way, for a premise that generates a new slideshow each run rather than a new video. Neither of those is the same thing as scheduling a single post for a specific future time — "publish this one video tomorrow at 9am" isn't a cron expression at all, since there's no recurrence involved, just one timestamp. That's a different, simpler mechanism entirely, checked and managed separately from any cron-based series.

    Setting one up in Versely

    Once a workflow's scenes and assets are already saved, turning it into a series and pointing it at social accounts is one request:

    "Run this workflow every Monday, Wednesday, and Friday at 9am UTC, and post the result to TikTok and Instagram."

    Because the workflow was already saved with its scenes and asset map, there's nothing blocking the schedule from attaching. The agent translates the cadence into 0 9 * * 1,3,5, and — because auto-posting was part of the request — confirms the TikTok and Instagram connections are actually live before turning the schedule on, rather than setting up a cadence that would generate content with nowhere to publish it. From there, each tick writes a fresh script around the same characters and style rather than replaying the same clip, so the series stays a series rather than a loop.

    Turning it off later doesn't mean deleting anything: calling the same scheduling tool again with the series set to inactive stops future runs while leaving the workflow itself intact, ready to be reactivated with the same cadence whenever it's needed again. The full mechanics for the video case are covered on running a recurring video series, and the slideshow-specific version — same cron syntax, a different content type underneath — is on scheduling a recurring slideshow series. For the one-time-post case that's easy to mistake for a cron job, managing scheduled posts is where a single future-dated post actually gets checked or cancelled. Every saved workflow this can apply to — recurring or one-off — lives in the workflows library once it's been built once and is worth reusing.

    FAQ

    What does the asterisk mean in a cron expression?

    It means "any value" for that field — no constraint. 0 10 * * * pins the minute and hour but leaves day-of-month, month, and day-of-week wide open, which is what makes it run every single day rather than on a specific date or weekday.

    Is the schedule time my local time or UTC?

    UTC, unless a local time was explicitly converted before the expression was written. Versely's scheduling tools ask for your preferred local time when it's ambiguous and default to treating an unspecified time as UTC — worth confirming explicitly rather than assuming, since a missed conversion means the series runs at the wrong hour for your actual audience.

    Can I schedule a workflow that doesn't have scenes yet?

    No — the workflow needs a saved scenes array and asset map before a cron expression can attach to it. Build and save the workflow first, then schedule it; trying to schedule an empty or unsaved draft is the most common reason a series doesn't behave as expected.

    How do I stop a recurring series without losing the workflow?

    Call the same scheduling tool again with the series set to inactive. That stops future runs immediately while keeping the saved workflow, its scenes, and its cadence intact — reactivating it later takes one call rather than rebuilding anything.