Cron Sink

The Cron sink triggers an event on a recurring cron expression or at one future local date and time.

Execution targets

Target	Scheduler	Availability
Local	Scheduler inside the desktop app	Runs only while the app is open
Remote	The hub’s configured scheduling backend	Runs independently of the desktop app
Hybrid	Both schedulers register the event	May create two runs for the same scheduled time
Device	The service the event is deployed to, on a device you manage	Runs while that service runs; see On a device

For a conceptual view of how both paths converge on the event, see Event Sinks.

Configuration

Field	Type	Meaning
expression	string or null	Five- or six-field cron expression for a recurring schedule
scheduled_for	object or null	One-time { "date": "YYYY-MM-DD", "time": "HH:MM" } value
timezone	string	IANA timezone; defaults to UTC
sink_execution	LOCAL, REMOTE, or HYBRID	Where the schedule is registered when both environments are available

A schedule uses either expression or scheduled_for, not both.

Recurring schedule

Flow-Like accepts the standard five-field form:

minute hour day-of-month month day-of-week

Position	Field	Range
1	Minute	0–59
2	Hour	0–23
3	Day of month	1–31
4	Month	1–12
5	Day of week	0–7; Sunday is 0 or 7

Flow-Like also accepts a leading seconds field:

second minute hour day-of-month month day-of-week

Hosted schedulers differ. AWS EventBridge Scheduler and Kubernetes CronJobs are minute-precision, so use five fields—or 0 or * in the seconds position—when a schedule includes those remote targets. The event editor flags incompatible expressions.

Expression	Meaning
0 * * * *	At minute 0 of every hour
0 9 * * *	Every day at 09:00
0 9 * * 1-5	Weekdays at 09:00
*/15 * * * *	Every 15 minutes
0 0 1 * *	First day of each month at midnight
*/30 * * * * *	Every 30 seconds; local or another seconds-capable scheduler only

Lists (1,15,30), ranges (1-5), and steps (*/15) are supported by the cron parser. Validate the expression in the event editor because provider-specific translation can reject combinations that a local parser accepts.

One-time schedule

{
  "scheduled_for": {
    "date": "2026-08-15",
    "time": "09:30"
  },
  "timezone": "Europe/Berlin",
  "sink_execution": "REMOTE"
}

The runtime resolves the date and time in the selected IANA timezone. A one-time local schedule is removed after it fires; remote behavior is implemented by the configured scheduler.

Timezones and daylight saving time

Use an IANA name such as UTC, Europe/Berlin, or America/New_York. Avoid fixed numeric offsets for civil-time schedules because they do not express daylight-saving transitions.

Local scheduling resolves the next occurrence in the chosen timezone. Remote providers receive that timezone where their API supports it.

Trigger payload

Cron does not promise a portable synthetic payload containing scheduled_time or actual_time. The desktop scheduler and the Docker Compose scheduler can invoke the event without a trigger payload, while a provider integration may attach provider metadata.

If the workflow needs stable context, put it in the event’s configured payload or derive it inside the flow. Treat any provider metadata as optional.

Missed and duplicate executions

• Do not assume a missed occurrence will be replayed after the desktop app or scheduler returns.
• A hosted provider may retry failed delivery; the internal service endpoint supports idempotency keys for callers that supply them.
• Hybrid scheduling intentionally registers more than one delivery path and can therefore produce duplicate real-world invocations.
• For critical schedules, make the workflow idempotent and record the business period it is processing.

On a device

A schedule, recurring or one-time, can be deployed to a device as part of a service, next to pages, endpoints and background flows. The sink_execution field does not decide this: deploying the event does. A Cron event that has a default Page is deployed as that Page, and the device does not run its schedule.

A device applies these rules:

• One place. For an online app, only someone who can edit the app’s events can move a schedule to a device; the deploy does it for them. The hub stops running the schedule once the service on the device has taken it over, and no second service can take it. Stopping the service does not hand it back: nothing runs it until the service starts again, the event leaves the service, or someone who can edit the app’s events chooses to run it on the hub again. When the service’s cloud access ends, the hub takes the schedule back by itself and runs it again from 65 minutes after the end. An offline app has no coordinator, so the desktop app and each device it is deployed to run their own copy.
• The documented syntax only. Five fields, or six with one fixed number in the seconds field. Day of week 0–7 with Sunday as 0 or 7, and three-letter month and weekday names. ?, L, W, # and shortcuts such as @daily are not accepted. When day of month and day of week are both set, either one matches.
• Once a minute at most. A seconds field with *, a list, a range or a step is refused.
• Timezone. The schedule’s timezone, or UTC when none is saved. The device’s own timezone is never used; its clock is.
• No run at start, no catch-up. The first run of a recurring schedule is the first scheduled time after the service started. A time that passed while the device was off, asleep or restarting is skipped, and a time the device notices more than a minute late is counted as missed.
• No overlap. A scheduled time that arrives while the previous run of the same schedule is still going is skipped. A service runs at most eight scheduled runs at once, and a run is stopped after 24 hours.
• Daylight saving time. In a recurring schedule, a local time that occurs twice runs once. A local time that does not exist runs at the first minute after the gap. An “every N minutes” schedule does not run during the repeated hour.
• The deployed version. The device runs the event version it was deployed with. Pausing or editing the event takes effect on the device with the next update of the service.

A payload object in the event configuration is passed to each run. For an online app, runs use the service’s cloud access and act as the person who approved it; they carry no personal access token and no signed-in provider tokens, so a flow that needs a signed-in provider works on the hub’s schedule and fails on a device.

One-time schedules on a device

A one-time schedule runs once, at its date and time in the schedule’s timezone, by the device’s clock. The time of the deployed event version counts.

• Never twice. The device records the run before it starts and keeps that record across restarts, updates, Start, rollbacks and clock changes. A run that a stop, an update or a crash cut off is not started again.
• Up to 15 minutes late. When the device was asleep at its time, or the service was restarting, updating or stopped, the schedule still runs if the service is back within 15 minutes and had it armed before its time. Later than that it is missed and never runs. When all eight run slots of the service are busy at its time, it waits for one within the same 15 minutes.
• Time had passed. When its time was already over the first time the service could run it, it does not run and is shown as time had passed: it was deployed after its time, the hub or another service held it over its time, or the hub handed it over at or after its time and may have run it itself. The deploy wizard does not add a one-time schedule whose time has passed and asks before adding one that is less than five minutes away. An update of a service that already has it is never blocked by its time.
• Exact local times. date is YYYY-MM-DD and time is HH:MM (no seconds), between the years 2000 and 2100. A local time that occurs twice because clocks go back runs at the first of the two. A local time that does not exist because clocks go forward is refused: choose a time outside the gap.
• It stays assigned. After it ran, was missed or had passed, the service keeps running and keeps the schedule. A new time set in Events runs only after the service is updated; until then neither the device nor the hub runs it. When the service’s cloud access ends, the hub does not take a one-time schedule back by itself, because it has no later time at which it would notice: someone who can edit the app’s events chooses to run it on the hub again.
• The device’s clock decides. A device whose clock is ahead runs it early, and then never again. A clock that is more than 15 minutes past its time when the service first has it ends it as time had passed or missed; setting the clock right afterwards does not bring it back.

Device agents from before one-time schedules refuse them; update the device agent to deploy one.

Operational checks

1. Confirm the event and sink are active.
2. Check the event editor’s next-run preview.
3. For remote schedules, verify the scheduler resource or worker is present.
4. Inspect the resulting run status and logs rather than relying only on scheduler delivery logs.

Limitations

• Remote precision and accepted cron syntax depend on the selected scheduling backend.
• Overlap prevention is not implicit; use workflow-level locking or idempotency when one run must finish before the next begins.
• Scheduling a range such as 28-31 does not mean “last day of month.” Add a calendar check inside the workflow.