Schedules

A schedule starts a saved workflow on a timetable, with the same input and budget each time. Every start is an ordinary run: recorded, charged and destroyed like one you started yourself.

A schedule

A schedule names a workflow, a timetable in cron syntax and a time zone, and the input and budget for each run. For example, every weekday at 09:00 in Tokyo, look up yesterday's new customers and send each a welcome email through a connection:

{
  "workflow": "welcome-new-customers",
  "name": "Weekday welcome emails",
  "cron": "0 9 * * 1-5",
  "timezone": "Asia/Tokyo",
  "input": { "signed_up": "yesterday" },
  "max_cost_micros": 200000
}

The dashboard builds the timetable for you under Schedules: every few minutes, hourly, daily at one or more times, on chosen weekdays or days of the month, or any cron expression. It shows the next start times before you save.

Timetables

A timetable has five fields: minute, hour, day of the month, month and day of the week. Each takes a value, a list (1,15), a range (1-5), a step (*/15) or *. Shorthands work too.

Times are read in the schedule's timezone, an IANA name such as Europe/Madrid, so a 09:00 schedule stays at 09:00 across daylight saving changes. Schedules start at most once a minute.

How starts work

• Ephemeral checks for due schedules every few seconds and starts each one as if you had called POST /v1/runs with the workflow, input and budget. The run records which schedule started it.
• Each start time runs once. If Ephemeral was unavailable when starts were due, the schedule runs once when it is back, then keeps to its timetable.
• By default a start is skipped while the schedule's previous run is still going, and the schedule notes it. Set skip_if_running to false to let runs overlap.
• If a start fails, for example because the workflow was deleted or there are not enough credits, the schedule records why and tries again at the next time. After five failed starts in a row it pauses; turning it back on resets the count.

Following scheduled runs

Scheduled runs appear with your other runs and carry a schedule_id. List one schedule's runs with GET /v1/runs?schedule={id}. Schedules do not send callbacks; to act on the result, have the workflow do it through a connection, or poll the schedule's runs.