Schedules
Put a finished workflow on a recurring schedule. Every setting you choose is applied to each run, and every run is recorded.
Create a schedule
Open the workflow's menu
In the Projects panel, open the workflow's ··· menu and choose Schedule DAG. A workflow has one schedule; to change it, edit it on the Schedules page.
Choose the model
Runs on, at the top, is the model every run uses. It starts as the model chosen in your chat.
Set the cadence and save
Choose how often it runs and when, then Save schedule. The other tabs start from sensible values; each number field shows the range it accepts.
The four tabs
| Tab | What you set |
|---|---|
| Cadence | Hourly (at which minute), daily, weekly (which days), monthly (which day) or a custom cron; the time and timezone; an optional start and end; and what happens to a start that was missed, for example while the server was down: run it once now, skip it, or run every missed start in turn. |
| Concurrency | What happens when the next start comes while the previous run is still going: skip the new start (Forbid), run both (Allow), stop the old run and start the new one (Replace), or start once the old one has finished (Queue). Also how many steps may run at once, and a random delay added to each start to spread load. |
| Guardrails | Hard caps for one run, its retries included: input tokens, output tokens and cost - the run stops as soon as one is reached; 0 is no limit. Also the attempts each step has, and schema gating: a step whose inputs are not the types it expects fails before any model call. |
| Resilience | Retries: how many, the first delay and how it grows (exponential, linear or fixed); a retry runs only the steps that failed. Time limits for the whole run, retries included, and for each step. And a dead letter target - a webhook, Slack or PagerDuty - told when a run fails every attempt. |
The Schedules page
Open Schedules from the left rail. The period at the top - one month ending now, unless you pick other dates - sets which runs are shown.
| Part | What it shows |
|---|---|
| Overview | Active and paused schedules, runs in the period, how many failed, the success rate, what they spent, and the next run. |
| Runs over time | Each day's runs by how they ended, and what they spent. |
| Schedules | Each schedule: its workflow and project, when it runs, its model, its status, its latest runs as coloured marks, and its next run. Open one to see every setting and each of its runs: when and how it started, how it ended, its attempts, how long it took, its tokens and cost, and any error. |
On each schedule: Run now (it follows the schedule's concurrency setting), Pause or Resume, Edit, or Delete, which also deletes its run history. Deleting the workflow deletes its schedule.
How a run can end
| Status | Meaning |
|---|---|
| Succeeded | Every step succeeded. |
| Failed | A step did not succeed after the run's retries. |
| Timed out | The run passed its time limit. |
| Over budget | The run reached its token or cost cap. |
| Skipped | The previous run was still going and the concurrency setting is Forbid. |
| Replaced | A newer run replaced it (concurrency setting Replace). |
| Refused | Your plan's usage for this billing period is used up. |
| Interrupted | The server stopped while the run was in progress. |
A run that does not succeed raises the Scheduled run failed alert when it is turned on in Guardrails.
How reruns stay consistent: Reruns replay saved code.