Pipeline scheduling
The built-in job scheduler runs one pipeline at the times a cron pattern names, in the time zone you choose. You see the next runs before you save, every run keeps a history of what happened to it, and a run whose outcome nobody can confirm stops the schedule until a person looks. Recurring work stops being somebody's calendar reminder.
How it works
A schedule names a pipeline in your workspace, a five-field cron pattern such as 30 2 * * * and an IANA time zone such as America/New_York. A fixed offset is refused, because it cannot follow a region's daylight-saving rules.
The preview lists the next occurrences with their local time and offset, from the same function the dispatcher uses. A time inside a spring-forward gap runs at the transition, so a daily job never silently skips a day; a repeated fall-back hour runs once.
If no instance was dispatching, skip, the default, records the missed occurrences as one summary row. latest runs the most recent missed occurrence once, if it is at most a day old. Paused time is never counted as missed.
A DATE parameter can take TODAY or YESTERDAY, resolved on the occurrence the run was due for in the schedule's time zone. A run due at 23:55 that starts at 00:05 still reports the day it was due for.
POST /api/v1/schedules
{
"name": "finance/daily/revenue",
"cron": "30 2 * * *",
"timezone": "America/New_York",
"missed_run_policy": "skip",
"payload": {
"pipeline": "finance/pipelines/daily_revenue",
"version": "current",
"parameter_bindings": {
"as_of_date": { "source": "keyword", "name": "YESTERDAY" }
}
}
}The create request as the REST contract defines it. The routes take a signed-in session; the Schedules page in the application makes the same calls.
Running it
Pause stops new runs; resume counts forward from now. Run now records a manual run, works on a paused schedule, and is refused on a blocked one or while another run of the same schedule is active. One schedule never overlaps itself.
Each run is recorded before anything launches and ends in exactly one state, with a trail of what happened to it: recorded, claimed, started, finished, retried or blocked, and why.
If an instance dies mid-run, nobody can say whether the work happened, so the schedule blocks instead of firing again and loading twice. A person reads the run and unblocks it, which re-validates the saved settings.
A schedule runs as the deployment's System account, which may only read pipelines, execute them and read executions. A creator who leaves the workspace does not stop their schedules, and nobody gains power through one.
Every member can read schedules, with promoters limited to pipelines they can see. Authors, workspace admins and super admins create, edit, pause, resume, unblock, delete and run them. The application's buttons follow the same rules, and the server enforces them.
Four scheduled runs at once per instance, at least five minutes between occurrences and a hundred schedules per workspace, by default. Each limit is a setting an operator can change.
Current limits
Try it
Run the server locally with the tutorial, let an agent author a pipeline and release it, then open Schedules in the application's Operate group. The same pipeline can also serve a published API or feed a dashboard; a schedule runs it, it does not refresh either of them.
A schedule covers one pipeline on a timetable. Dependencies between jobs, range backfills and sensors belong to an orchestrator: the Airflow comparison draws that line, and Dagster vs Airflow helps when you are choosing one.
Asked before
Yes, when scheduler mail is enabled and the schedule has recipients. Failure, unknown and blocked events default on; start and success are opt-in. Scheduler mail is off by default, and the deployment's mail and recipient-domain policy still apply. Reports, condition alerts and PDF delivery are not built. The contract is docs/scheduler.md §2.3.
The one the pipeline's current-version pointer names when the run is prepared, and a person can point that at a draft under the development posture. Each run freezes the exact version and the resolved parameter values it launched with, so its history says what actually ran. The contract is docs/scheduler.md §2.1.
No. Nothing about a schedule is exposed over MCP. Authors, workspace admins and super admins create, edit, pause, resume, unblock, delete and run schedules in the application or over the REST API with a signed-in session; every workspace member can read schedules, with promoters limited to pipelines they can see. The schedule job is docs/scheduler.md §1; its execution identity is docs/scheduler.md §6.
The scheduler is a job scheduler; pipelines are the job type it runs today. This page's example schedules a SQL pipeline. The scheduler stores the payload without reading it, so a report or AI job would be a new job type, decided later, not a capability to count on today. Pipeline scheduling is the example this page walks through. The contracts are docs/scheduler.md §1 and docs/scheduler.md §2.