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 |

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.

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.