Scheduling

A schedule starts runs without anyone pressing a button. Set it once in the pipeline’s Settings › Schedule (or by clicking the schedule line in the statement of work, or by asking Jason) and the pipeline keeps its dataset fresh on its own.

1. Slot arrivesin the schedule's timezone
2. Checksworkspace live, no active run
3. Live runsame as a manual run
4. Verifyend-of-run checks
5. Publishnew dataset revision
6. Next slotcountdown restarts

Setting a schedule

1. Open Settings. On the pipeline page choose How it works, then Settings in the rail. The Schedule tab is first.
2. Pick a cadence. Hourly, Daily or Weekly. Off is the default for a new pipeline.
3. Set the details. Days and time for daily and weekly; interval, days and an optional window for hourly. Read the preview line, for example 3 days each week at 09:00 · 3 runs/week.
4. Check the timezone. Your browser’s zone is preselected. Change it if the data should follow another region’s day.
5. Save Schedule. The button reads Saved! and Next run in appears with a countdown.

Every field, its values and its validation messages are listed in Settings reference. In short:

Cadence	Fields	Result
Hourly	Repeat interval (1 to 24 hours), Days, optional Only run between set hours with Start and End	Runs every n hours on the chosen days, inside the window if set. The end time itself is not a slot.
Daily	Time	One run every day at that time.
Weekly	Days, Time	One run on each chosen day at that time.
Off	—	Runs start only manually, from a webhook, or from Jason.

Or say it to Jason, who sets the same fields:

Run this every weekday at 06:30 London time, and only on Saturdays at 09:00.

Jason will point out that a single schedule has one time, and offer weekday runs at 06:30 with a separate weekend arrangement if you want one.

Time zones

Every time in the schedule is read in the schedule’s Timezone. Daylight-saving changes follow this timezone automatically.: a run set for 06:00 Europe/London starts at 06:00 local time in both winter and summer.

The timezone matters for two other things:

• Relative date parameters. A parameter such as since = yesterday is resolved against the pipeline’s calendar timezone, not the schedule’s. Keep the two the same unless you have a reason not to. See Relative dates.
• How times are shown. The hero’s next run in 6h 12m, the card’s Next run Tue 06:00 GMT+1 and the Home page’s Scheduled list all show the schedule’s zone, so a colleague in another region sees the same clock time you set.

A workspace collecting US retail prices from a team in London usually wants the schedule in America/New_York so the run lands after the retailers’ overnight price updates, whatever the season.

Where the next run is shown

Place	What you see
Pipeline hero	next run in 6h 12m, counting down; next run due when the slot has arrived and the run is about to be picked up.
Pipeline card	A clock with the cadence (Daily) in the corner and Next run Tue 06:00 GMT+1 under the status.
Home › Scheduled	The next five upcoming runs across the workspace, soonest first, with Running in 0:42:10 or Run due. Jason’s own timed tasks appear in the same list marked Jason task.
Settings › Schedule	Next run in with the countdown and the absolute time in the schedule’s zone.
Statement of work	The schedule line: Runs every day at 06:00 (Europe/London).

What a scheduled run does

A scheduled run is a Live run, identical to one you start by hand, with these particulars:

• Defaults throughout. It uses the pipeline’s default item limit, your parameter defaults from the Inputs page, and the current revision of every dataset input. There is no dialog; to change what scheduled runs do, change the defaults.
• Started by timer. The runs rail and Latest runs show by timer; the Started from filter on Latest runs finds them under Schedule.
• Publishes on success. When its checks pass, each output becomes a new dataset revision and every connected destination, dashboard and newsletter picks it up. See Verification and repair.
• Repairs on failure. If it fails and Enable Auto Heal is on, Jason starts a repair without being asked. Manual runs never do.

Skipped slots

An active run causes that scheduled slot to be skipped. If the previous run is still going when the next slot arrives, that slot is skipped and the schedule carries on from the following one. Nothing queues up.

Scheduled runs also do not start while:

• the workspace is out of rows for the month (the banner reads Pipelines are paused until the next reset or top-up), or
• workspace access is paused, in which case the schedule editor reads Workspace access is paused. Resume access to schedule collection.

A scheduled pipeline whose last successful run is older than two slots turns amber with No recent successful run, on its card and in Home’s Needs attention, so a silently skipped schedule does not go unnoticed. Alert rules can send that to Slack or email.

An hourly schedule with a pipeline that takes 70 minutes runs every two hours in practice. Either widen the interval or ask Jason to make the pipeline faster.

Pausing and stopping a schedule

• Pause. Set the cadence to Off and Save Schedule. Nothing else changes; the pipeline, its defaults and its datasets stay. Set the cadence back when you want it running again.
• Stop a run that has already started. Open the run and press Stop, or Stop on its card on Latest runs. The next slot still fires. See Run lifecycle.
• Keep the schedule but exclude a source. Turn the item off on the Inputs page; the next scheduled run leaves it out.
• After a copy or move. A pipeline transferred to another workspace arrives with its schedule off. Set it again in the new workspace.

What’s next