Skip to main content

​
Schedule Trigger

A schedule trigger runs a flow at a moment you choose, and then repeats it at a fixed interval. It is deliberately small: one start time, one interval, one payload. There is no cron expression, no calendar, no timezone selector and no pause switch.

​
Configuration

The schedule editor has six fields and nothing else.

​
Trigger Every

A whole number followed by one unit: 45m, 2h, 1d, 2w, 3M, 1y. Anything else is rejected — a decimal (1.5h), a negative, a bare unit and a compound (1h30m) are all refused.
M and y are fixed durations, not calendar arithmetic. 1M is 30 days regardless of the month, and 1y is 365 days, so a yearly schedule drifts a day every leap year.
The editor marks anything under 5m as invalid, but it does not block saving and the platform accepts it. Treat five minutes as the floor even though nothing enforces it.

​
Trigger On and time zones

There is no timezone control anywhere on this trigger. The picker works in your browser’s local time and stores the absolute instant you chose. The server never re-reads a wall clock. The consequence is worth stating plainly: repeats are fixed offsets from the previous run, so a 1d schedule set for 09:00 keeps running at the same absolute moment across a daylight-saving change — which will read as 08:00 or 10:00 locally afterwards, permanently.

​
Trigger Input

Whatever you type becomes $.trigger, verbatim.
  • Plain text — $.trigger is that string.
  • JSON — $.trigger is the parsed object.
  • Empty — $.trigger is the empty string "".
Nothing is added. There is no fire time, no schedule name, no occurrence counter and no flag saying the run was scheduled. A flow cannot tell from $.trigger that a schedule started it. If a step needs the time, take it from a date function inside the run.

​
Schedules only exist once you publish

A schedule is created when the flow is published, not when it is saved. The editor says so: “Changes to this trigger will become active once the flow is published.” The platform refuses to schedule a draft outright — the error is the flow subject cannot be draft.
Publishing does the whole job in one pass: it removes the schedules belonging to the previously published version and creates them from the version you just published. That gives a simple rule for every change: There is no Enabled toggle to switch a schedule off, and deleting the node without publishing leaves the old schedule running.

​
Naming

A schedule’s identity is the account, the published flow, and the trigger node it came from — so two schedule triggers on the same flow may share a Name and both still fire. The Name is still worth setting properly. It is what identifies the schedule in the editor, and it is the only label you have when a flow carries several.

​
Execution

​
The first run

At the moment given by Trigger On. Set a time in the past and it fires as soon as the flow is published.

​
Repeats

Each run schedules the next one when it starts, as now plus the interval — not as the previous scheduled time plus the interval. Two things follow: Runs overlap. The flow is launched and the next occurrence is armed immediately; nothing waits for the run to finish. An interval shorter than the flow’s runtime means several copies running at once. There is no concurrency limit, no skip-if-running and no queue. The schedule drifts later. Each cycle adds whatever delay there was between the due moment and the actual fire. A “daily” job creeps later every day and never corrects itself.
If drift matters, use a shorter interval and make the flow’s first step decide whether there is anything to do — a Condition on the current time, or on whether work is outstanding.

​
Failures

A run that errors still arms the next occurrence. There is no retry, no backoff and no alert; the failure appears in Monitoring and nowhere else.

​
Downtime

The next occurrence is held in durable storage, so a restart does not lose a schedule. On restart, an occurrence that came due while the platform was down fires once, immediately — and the interval then restarts from that moment.
There is no catch-up. A five-minute schedule that missed six hours produces one run, not seventy-two. The skipped occurrences leave no record.

​
Runs are always detached

A scheduled run never waits for a result and never returns one, so nothing about the flow’s outcome reaches the scheduler. Everything the run produces has to be written or sent by a step.

​
Reading the payload

With Trigger Input Type set to JSON and this input:
With Plain text, $.trigger is the whole string and there are no sub-paths.
What runs after the trigger is decided by each step’s outcome, not by the arrows in the editor. A Condition step’s outcome names the step IDs to run next — one, several (they start at the same time), or the reserved RESOLVE_SUCCESS / RESOLVE_ERROR to end the run. A line drawn between two steps that no outcome names is decoration.

​
Troubleshooting

Almost always because the flow has not been published since the trigger was added. Save does not create a schedule; Publish does.
Publish the flow. Schedules are rebuilt from the published version at publish time and at no other point.
Publish the flow. The unschedule happens during publish.
The interval is shorter than the flow takes. Lengthen it, or have the flow exit early when a previous run is still in progress.
Expected. The start time is an absolute instant and repeats are fixed offsets — nothing re-reads a wall clock. Edit Trigger On and publish to move it back.

​
Next Steps

Condition Step

Decide at run time whether there is work to do

Flow Steps

What the scheduled run can do once it starts

Variable Mapping

Reading the trigger input in later steps

Triggers Overview

Every way a flow can start