ScheduledCopy Anchor Link

Start Scheduled (startScheduled) is the start node for a graph that the platform fires from a clock. It is a saved graph entry point, not an external request that the flow receives from a caller.

A flow has one start node. Use Start Scheduled instead of Start when the scheduler, rather than Actionflow Studio, an API key, or a webhook, should start the graph.

ConfigureCopy Anchor Link

The Start Scheduled sidebar supports these schedule types:

The sidebar also stores a cron representation for recurring and weekly schedules. The scheduler can read the structured fields or the supported cron fallback. A schedule is incomplete when a recurring interval value/unit, a weekly weekday, or a one-time runAt value is missing; an incomplete schedule has no next run. In imported or legacy weekly data, when no clock fields are supplied, the clock falls back to 00:00 unless a valid weekly cron fallback supplies it.

Use an IANA timezone such as UTC, Europe/Istanbul, or America/New_York. The selected timezone is stored with the schedule and is used for the wall-clock calculations described below.

Next-run calculationCopy Anchor Link

For example, a weekly Monday at 09:00 in Europe/Istanbul is stored as a local schedule and converted to the corresponding UTC instant when the next run is calculated. A recurring minute or hour interval is interval arithmetic in UTC, so its displayed local time can change when daylight-saving time changes.

Timezone and DST behaviorCopy Anchor Link

Daily, weekly, and offset-less one-time schedules use the selected IANA timezone when converting local date and time fields to UTC. A spring-forward wall-clock gap is normalized forward: for example, on the America/New_York transition date, a daily or weekly 02:30 schedule becomes 03:30 local time. For a fall-back repeated wall-clock time, the converter selects one occurrence; it does not create a second run or an extra catch-up run. The scheduler advances to the next computed occurrence after a gap or repeat.

When a tick firesCopy Anchor Link

The scheduler claims due active, non-template flows, advances their stored nextRunAt, and enqueues one run with triggerSource: "schedule". The run trigger includes the claimed scheduled timestamp in its body. A scheduled tick creates an independent run and run-history record, plus a queue record when the queue is enabled; it does not reuse the previous run.

The scheduler task itself is limited to one concurrent tick, but that limit does not serialize the resulting flow runs. If one scheduled run is still executing, a later tick can create another run. When the organization run queue is enabled, the queue may hold the later run until the organization concurrency check allows dispatch; when it is disabled, the execution service applies its own task/concurrency behavior.

Missed and failed occurrencesCopy Anchor Link

The current missed-run policy is skip, do not backfill:

1. A due row is claimed once and produces one run using the claimed due timestamp, even if the claim happens late.
2. The next occurrence is calculated from the current claim time. If the scheduler was unavailable across several intervals, the flow does not replay every missed interval; it admits only the single claimed occurrence and then advances to the next calculated future occurrence.
3. If enqueueing the claimed occurrence fails, the scheduler restores the previous due timestamp when it is still unchanged so a later tick can retry that occurrence. This is a retry of the failed admission, not a promise that every missed interval will run.

Current limitation: The scheduled retry uses the deterministic admission key schedule:{actionFlowId}:{claimedAt}. Admission is looked up by organization, ActionFlow, and that key. If a terminal failed or cancelled admission already exists for the key, enqueueFlowRun returns an unavailable-admission error instead of opening a new run. Restoring nextRunAt permits a later retry only when no terminal admission blocks the same key; repeated failures can otherwise persist.

A one-time schedule is cleared after its due occurrence is claimed, so it does not repeat. A claim made after runAt has passed can still admit that one late claimed occurrence, but there is no second catch-up run. A runAt that is already in the past when a new schedule is resolved produces no future nextRunAt. Passive flows are not claimed, and stopping or deactivating a flow clears its scheduled next-run time.

Validation timingCopy Anchor Link

The scheduled direct path does not perform the API/webhook pre-enqueue validateFlow check. A scheduled run can therefore have a history row before the graph fails during execution. When the flow queue is enabled, the queue consumer validates the saved graph before dispatching the queued run, so a queued history row can still be marked failed for validation. See Flow execution model and Flow troubleshooting.

ExamplesCopy Anchor Link

• Every 15 minutes for a short polling loop.
• Every 2 days at 09:30 in Europe/Istanbul.
• Every Friday at 10:00 in America/New_York.
• One time at 2026-09-30T09:00 in Europe/Istanbul; the local time is converted using the selected timezone.

RelatedCopy Anchor Link

• Manual for on-demand runs
• API for a separate non-scheduled graph
• Run history
• Settings for active state
• Flow troubleshooting