Skip to Content
Core WorkflowsSchedules

Schedules

For sending and tracking requests by hand, see Runner Requests. This page covers how to dispatch the same request automatically on a recurring schedule.

A schedule turns task instructions you write in plain language into runner requests at a fixed time, daily or weekly. Instead of typing the same prompt every time, the saved instructions are queued as a pending request each cycle and a runner picks it up and executes it.

Create a schedule

In the web app, select your team and project, open Project Settings, go to the Schedules tab, and click Add schedule.

FieldWhat you enter
TitleThe name that identifies the schedule in the list and dispatch history
Task instructionsThe prompt sent to the runner. It is carried into the dispatched request as-is
FrequencyDaily or Weekly
Day of weekThe day, when Weekly is selected
Run timeThe time of day to dispatch
Time zoneThe IANA time zone the run time is read in (for example, Asia/Seoul)
Dispatch targetsWhether to dispatch to one runner or to several runners at once
RunnerThe single runner that executes the request. Leave empty to use the Agent’s Runner
AgentThe agent configuration that takes the request
Engine / modelAn engine and model supported by the selected runner
RunnerBoxWhether to run in an isolated workspace. When on, a repository and base branch are required
EnabledWhether recurring dispatch starts as soon as you save

Enter the time zone as an IANA name. If the format is not valid, Enter a valid IANA time zone. appears and the schedule is not saved. If the agent or engine is not available on the selected runner, the save button stays disabled.

The Schedules tab is visible to members who can view runners. Creating, editing, toggling, deleting, and Run now require permission to change runners.

Dispatch to multiple runners

Switching Dispatch targets to Multiple Runners sends the same task instructions to several runners in the same cycle. The list shows your own runners only; runners shared with you by other members cannot be selected.

  • Pick one Agent per runner, from the agents connected to that runner. A runner with no connected agent is shown as unselectable with No Agent is connected to this Runner.
  • Select all selects every runner you can choose at once. One schedule can target up to 20 runners.
  • Dispatches to N Runners appears next to the save button.

The engine and model are not set per runner — they are shared by every selected runner. Only values that all selected runners support can be chosen, so adding a runner removes the values that are no longer common and resets a value you already picked. If the selected runners have no engine in common, The selected Runners have no engine in common. appears and the schedule cannot be saved.

Each cycle creates one request per runner, so the amount of execution grows with the number of runners. Dispatched, skipped, and failed are decided and recorded per runner. If one runner’s previous request is still open, only that runner is skipped and the rest are dispatched as usual.

If a runner loses access to the engine after the schedule is saved, only that runner is skipped in that cycle with the reason The engine is unavailable on this Runner. The other runners are dispatched as usual.

People start it, people review it

Creating a schedule and leaving it Enabled is the act that approves recurring execution. While it is enabled, requests are dispatched at each scheduled time without approving every cycle again.

Results are not applied automatically. Reviewing what each cycle did and deciding whether to accept the change is yours. Open the results with their prompt, logs, and conversation history in Runner Requests.

Overlap prevention

Cycles of one schedule never overlap. If the request dispatched previously is still pending or running when the scheduled time arrives, that cycle is not dispatched and is recorded as Skipped.

A schedule that dispatches to multiple runners makes this decision per runner. When one runner is skipped, the cycle is still dispatched for the others.

A skipped cycle is not dispatched later in a batch. Missed past times are not caught up — the schedule resumes normally at the next scheduled time. A cycle is skipped the same way when the agent configuration it points to is unavailable.

Check dispatch history

Each schedule in the list shows Next run, Last run, and Latest dispatch result. Times are shown in that schedule’s time zone. Click Dispatch history to see each cycle with its scheduled time.

ResultMeaning
DispatchedA runner request was created
SkippedThe cycle was not dispatched. A reason is shown alongside
FailedThe request could not be dispatched

For a schedule that dispatches to multiple runners, one cycle is recorded as one row per runner, and each row shows the runner name.

Skip reasons appear as The previous run is still active. or The execution environment is unavailable. The first means the previous cycle has not finished; the second means the agent configuration the schedule points to can no longer be used, so edit the schedule and pick the execution environment again.

Progress, logs, cancelling, and retrying a dispatched request are covered in Runner Requests.

Run now, disable, delete

  • Run now — Dispatches once without waiting for the scheduled time. A schedule with multiple runners dispatches to every selected runner. The Next run time stays as it is. If the previous request is still open, this is skipped too.
  • Disabled — Turning the toggle off in the list stops recurring dispatch and Next run becomes None. The schedule and its dispatch history remain, and turning it back on schedules the next run from that moment.
  • Delete — Removes the schedule after confirmation. Requests already dispatched remain in the runner request list.

Editing the frequency, day, time, or time zone recalculates Next run from the moment you save.

Last updated on
Runner RequestsPortal