Run a playbook automatically — on a cadence you pick, delivered to email and Slack.
A schedule runs a playbook automatically — once at a set time, or daily, weekly, or monthly. Each run produces that playbook’s artifacts in its project, just like running it by hand, and can deliver them straight to your inbox or a Slack channel. Set up the Monday-morning recap once and it lands before anyone asks for it.
The Schedules page — every schedule, with its playbook and next run
Click New schedule (top-right of /schedules) and pick the playbook to run — the list is searchable and shows each playbook’s project. You can also start from the playbook itself: Schedule in its toolbar or run dialog opens the same wizard with the playbook already chosen.
Pick the playbook to run
If the playbook takes runtime parameters — a week-ending date, a market, a team — the next step asks for the values this schedule should use on every run.
A date and time — the schedule runs a single time, then shows as completed
Daily
A time of day
Weekly
One or more weekdays, plus a time
Monthly
A day of the month, plus a time
Times are picked in 15-minute increments and interpreted in a timezone you choose — your browser’s by default — which is stored with the schedule so runs stay put when you travel.
Name, frequency, and delivery
PUT /v1/schedules/{scheduleId}
Update a schedule’s cadence, parameters, or delivery.
PUT is a full replace — the body is a complete create request, so any config field you leave out resets to its default (params={}, output_folder="/Reports", email_recipients=[], paused=false). A PUT that carries only a new cadence silently wipes the recipients. Read the schedule first, change the fields you mean to, and send the whole object back.
A scheduled run always saves its artifacts into the project. Turn on either notification to push them out as well.Email notification — add recipients, then pick which artifacts to attach. Each artifact has a single attach checkbox; a link to the artifact is always included, whether or not it’s attached. Recipients must be on your workspace’s allowed email domains. Recipients can unsubscribe themselves from a link in the email.Slack notification — post to channels or people in a connected Slack workspace, with the same per-artifact attach checkbox.
Email recipients and attachments
Slack channels and attachments
How each artifact arrives. Formats that are already final ship as themselves; the rest render to PDF:
Playbooks that declare their outputs get a row per output. For playbooks that don’t, the scheduler discovers the artifacts after the run and applies these same per-kind defaults.
POST /v1/schedules
Set email recipients when creating a schedule.
Recipients must be on the workspace’s invite-domain allowlist — a disallowed address returns 400 RECIPIENT_DOMAIN_NOT_ALLOWED. Slack can’t be set through this call: the public config model has no slack_recipients field and silently drops one if you send it. Per-artifact delivery isn’t exposed here either — it requires hand-building config.output_config.email.artifacts.
The Schedules page (/schedules, shown above) lists your schedules with the playbook each one runs, when it last ran, when it runs next, and who created it — with search. Click a row to open its details sidebar: the cadence, next run, the parameter values it runs with, and a history of past runs.
A schedule's details
Each schedule’s ⋯ menu (and the sidebar) holds the rest:
Action
What it does
Edit
Reopen the wizard to change the cadence, parameters, or delivery
Pause / Resume
Stop future runs without deleting the schedule, then start them again
Run now
Run the playbook immediately, without waiting for the next occurrence
Delete
Remove the schedule. Artifacts it already produced stay in the project
A schedule’s History timeline — in its details sidebar, shown above — lists each run with what it produced; open a run to jump to the artifact, or to the chat behind it. Runs in flight show as In progress with a live dot, finished runs are check-marked, and a failed run carries its reason.A schedule itself reads as active or paused; a one-time schedule that has already run reads completed, or failed if its single run failed. A recurring schedule stays active even when its runs keep failing. Runs from a schedule also appear in the Runs tab on the Playbooks page, alongside runs people started by hand.
GET /v1/schedules/{scheduleId}/runs
List a schedule’s runs.
POST /v1/schedules/{scheduleId}/runs
Run a schedule’s playbook immediately.
⌘I
Assistant
Responses are generated using AI and may contain mistakes.
