Flow Schedules

A schedule runs a Flow on a cadence, such as every 5 minutes, every weekday at 09:00, or 5 minutes after the previous run finishes. A Flow can have any number of schedules. Each run is a normal run of the Flow: it appears in the Flow's runs, uses credits, and logs the same way as a run started any other way.

What a Schedule Runs

Each run starts the Flow's latest published version, looked up when the run starts, so publishing a new version changes what later runs do. A Flow with no published version does not run; the schedule records The Flow has no published version as its last error and tries again at its next run.

Setting	Description
`name`	Required, 1–250 characters.
`triggerNodeId`	The `nodeId` of the Flow - Trigger node to start from. It must be a trigger node in a version of the Flow; otherwise the request is rejected with `400` (`The Flow has no trigger node '<nodeId>'`). When omitted, the published version's first trigger node.
`inputs`	The trigger's inputs, keyed by input name, for example `{ "region": "APAC" }`. Required inputs must be given, or the run cannot start. Default `{}`.
`logLevel`	`none`, `error`, `warn`, `info`, or `debug`. When omitted, the published version's default log level.
`timing`	When runs happen; see Timing. Required.
`runAs`	Whose identity runs are made as; see Who Runs Are Made As. Default `{ "type": "editor" }`.

Timing

timing.mode is absolute or sliding. A schedule can run at most once a minute, and a due run starts within a minute of its time.

Absolute

Runs fall on the occurrences of a recurrence rule, whatever earlier runs did.

Field	Description
`recurrence`	A recurrence value, in the same format as the `recurrence` field type. Local times keep their wall-clock time across daylight saving changes in the rule's time zone. `SECONDLY` rules, and rules with more than one `bySecond` value, are rejected.
`overlap`	What happens when an occurrence comes due while the schedule's previous run is still running. `skip` (default): the occurrence is skipped. `queue`: the run starts as soon as the previous run finishes.

The series ends at the rule's count or until, if it has one.

{
  "mode": "absolute",
  "recurrence": {
    "dtstart": "2026-01-05T09:00:00[Australia/Sydney]",
    "freq": "WEEKLY",
    "byDay": ["MO", "TU", "WE", "TH", "FR"]
  },
  "overlap": "skip"
}

Sliding

The next run is due a set interval after the previous run finishes, whether it succeeded, failed or was cancelled, so runs never overlap.

Field	Description
`interval`	An ISO 8601 duration, at least one minute, for example `PT5M` or `P1D`. Required.
`timeZone`	The IANA time zone that days, weeks, months and years are added in, so a `P1D` interval keeps the local time across daylight saving changes. Default `UTC`.
`startAt`	When the first run is due, as a date-time with an offset. Default: when the schedule is created or resumed.
`stopOnFailure`	`true` stops the schedule when a run fails. Default `false`.
`endAfterCount`	End the series after this many runs.
`endAt`	End the series when the next run would fall after this date-time.

{ "mode": "sliding", "interval": "PT5M" }

Missed Runs

When runs are missed, for example during a service interruption, the schedule runs once when it can, then carries on from its next due time. It does not run once for every missed occurrence.

Status

`status`	Meaning
`active`	Runs when due. `nextRunAt` is when the next run is due. For a sliding schedule it is empty while the previous run is still running.
`paused`	Turned off. `pausedReason` is `user` (paused by someone in the Space) or `imported` (arrived through a Space import).
`completed`	The series has ended.
`stopped`	A run failed and the schedule stops on failure.

A schedule also reports runCount (the runs it has started since it was created or last resumed), lastRunAt, lastFlowExecutionId (its most recent run), and lastError: why its last due run could not start, for example The identity this schedule runs as cannot run this Flow. lastError is cleared by the next run that starts.

Resuming a paused, completed or stopped schedule (setting enabled to true) starts its series afresh from now: an absolute schedule is next due at its next occurrence, and a sliding schedule at its startAt, or straight away when that has passed. Changing the timing of a schedule that is not paused does the same. Setting enabled to true on an active schedule changes nothing. A sliding schedule never starts a run while its previous run is still running, even when it has just been resumed or retimed.

Who Runs Are Made As

Runs are made as a Space identity, and are allowed to do what that identity is allowed to do. When a run is due, the identity must still be a member of the Space and be allowed to execute the Flow; otherwise the run does not start and the schedule records why in lastError.

{ "type": "editor" } (default): whoever last saved the schedule. Saving a schedule makes you its editor, so its later runs are made as you.
{ "type": "agent", "agentId": "<agent-id>" }: an agent of the Organisation that owns the Space. The agent must be a member of the Space. This option is not available in Spaces owned by a person; it is rejected with 400.

Permissions

Viewing and changing a Flow's schedules requires permission to update the Flow (a Space admin). Users without it get 404.

Export and Import

A Flow's schedules are included when the Flow is exported. Imported schedules arrive paused, with pausedReason set to imported and no identity to run as, so nothing runs in the target Space until someone reviews each schedule and resumes it, which makes them its editor. Check a schedule's inputs before resuming it: values that refer to Records in the source Space are imported unchanged. Creating a Space as a copy of another copies its Flows' schedules the same way.

API and CLI

Action	REST API	CLI
List	`GET /api/v1/spaces/{spaceId}/flows/{flowId}/schedules`	`ligantic flows schedules list <flowId>`
Show	`GET /api/v1/spaces/{spaceId}/flows/{flowId}/schedules/{flowScheduleId}`	`ligantic flows schedules show <flowId> <flowScheduleId>`
Create	`POST /api/v1/spaces/{spaceId}/flows/{flowId}/schedules`	`ligantic flows schedules create <flowId>`
Update, pause or resume	`PATCH /api/v1/spaces/{spaceId}/flows/{flowId}/schedules/{flowScheduleId}`	`ligantic flows schedules update <flowId> <flowScheduleId>`
Delete	`DELETE /api/v1/spaces/{spaceId}/flows/{flowId}/schedules/{flowScheduleId}`	`ligantic flows schedules delete <flowId> <flowScheduleId> --yes`

Pause a schedule with --enabled false and resume it with --enabled true. Deleting a schedule does not cancel a run it has already started.

ligantic flows schedules create <flowId> \
  --name "Sync every 5 minutes after the last one" \
  --inputs '{ "region": "APAC" }' \
  --timing '{ "mode": "sliding", "interval": "PT5M" }'

Invalid timing is rejected with 400, for example A schedule can run at most once a minute, The interval must be an ISO 8601 duration, such as PT5M, or Unknown time zone.

See the generated CLI command reference for every option.

Page not found. It may have moved or may not be published.

Browse documentation