Menu
Platform
AI
App store purchases
Database
Flags
Jobs and cron
Localization
Monitoring
Notifications
Payments
Queues
Sandboxes
Webhooks
Getting Started
Authentication
KV Store
Deploy & Infrastructure
Reference
Jobs and cron
What a Schedule is, what a fire is not, and the surface that runs schedules today.
A Schedule starts Runs of a Workflow on a calendar or an interval. Nothing calls it: every fire is an engine timer, so a schedule that is due fires even while nothing of yours is running.
(schedule, intended time) is the Run identity. One instant starts at most
one Run, however many times a wake is delivered, so a retry or a duplicated
wake cannot start the same instant's Run twice. And a fire is not a Run
result: the fire is what starts the Run, and how that Run ended is the Run's
own outcome.
#What you set on a Schedule
| Field | Type | What it is |
|---|---|---|
calendar.kind | string | The trigger: rate, a fixed period, or cron, an expression. |
calendar.everySeconds | number | The period of a rate, 1 to 31536000 seconds. |
calendar.expression | string | The 5- or 6-field cron expression of a cron calendar. |
calendar.timezone | string | The IANA time zone the calendar is read in. |
overlap | string | What a fire does while the previous Run is still running: skip, buffer_one or allow. |
catchUp | string | What a missed fire does: skip, last_only (only the most recent), or bounded by maxTicks or maxAgeSeconds. |
target | object | Where the fire lands: an http target (an https url, a method, signed set to true), or execute, which names a jobId and its expectedRevision. |
retry.maxAttempts | number | How many times a fire is retried. |
pause | bool | Whether fires are paused. |
A rate's first due time is one interval after the schedule is created, so a schedule made now with a 30-second rate first fires 30 seconds from now.
#Where the Runs go
On the surface that runs today, a fire lands on an HTTP target: a signed
request to an https URL, in the method the target states. HTTP
targets is the receiver's side of that. The declared
schedules collection describes the same object the other way round — its
Schedule names the Workflow to start, in the same environment.
#The surface that runs schedules today
Schedules run on the Sylphx Compute API, a service of its own with its own
base URL and its own key scopes, called with fetch. The SDK's workflows
module covers Workflow Runs, not these schedules. A request presents a
Sylphx Access key, Authorization: Bearer sylphx_sk_…, and schedules take the
workflows:read and workflows:write scopes.
The one API's schedules collection is the Schedule Resource as declared —
the name pattern, the spec, pause and resume — and
the schedules collection is where that shape is
written down. The calls that run today are the Compute API's.
- Base URL
- https://api.compute.sylphx.com
- Create
- POST /v1/schedules
- Read one
- GET /v1/schedules/{id}
- Delete
- DELETE /v1/schedules/{id}
- Scopes
- workflows:read, workflows:write
- Identity
- identity.resourceId, identity.revision
- Declared name
- orgs/{org}/projects/{project}/envs/{env}/schedules/{schedule}
The fields on that wire are camel case — everySeconds, catchUp,
lastTick, deadLetters — and an answer names the authority that gave it. An
error carries a code and a message rather than a status alone:
{"error": {"code": "conflict", "message": "…"}, "product": "Sylphx Compute", "authority": "compute"}.