Schedules

Schedules are stored, not run

You can create schedules today and they are kept with the project, but nothing executes them yet. The server-side runner is a later release.

If you are planning a process around a nightly import, plan for it to be triggered by something else for now. A schedule that exists but does not fire is worse than no schedule at all if you assumed otherwise.

Why they exist already

A project is meant to outlive the person who built it, and “run this on the first of the month” is part of the recipe, not a separate thing. Storing schedules now means:

• The shape is settled before anything depends on it.
• A project pushed from a configuration repository can carry its schedule, so the intent is in version control today.
• When the runner ships, existing projects already say what they wanted.

What a schedule holds

Name	What this run is.
Cron	A five-field cron expression: 0 2 * * * is 2am daily.
Timezone	An IANA zone, Australia/Sydney. Defaults to UTC.
Enabled	Off without deleting it.
Source configuration	Where the rows will come from when it fires.

Set the timezone deliberately. A nightly job defaulting to UTC runs at lunchtime in Sydney, which is exactly the sort of thing nobody notices until it matters.

Where the rows will come from

This is the part that makes a scheduled import different from an interactive one. Today, somebody brings a file. A scheduled run has nobody to bring it, so the schedule carries a source configuration saying where to fetch from.

The shape of that configuration depends on the source package, and the set of sources will grow. Until the runner exists, treat this as recorded intent rather than a working connection.

Limits

Your plan caps how many schedules an org can hold, and whether scheduled imports are available at all. Exceeding the cap is refused with LIMIT_SCHEDULES; a plan without the feature refuses with FEATURE_SCHEDULED_IMPORTS.

On Free and Team the cap is zero. See Plans and limits.

What to expect when the runner ships

Two things that are already true of the design and will not change:

• A scheduled run is authorised the same way an interactive one is. The row allowance is checked once, at the start, so a scheduled run that begins finishes.
• It appears in the same run history, with mode: server rather than widget, so you do not have two places to look.