Schedule (trigger.schedule)

Run the workflow on a recurring timetable. The editor shows a recurrence builder (every N minutes, hourly, daily, weekly, monthly, yearly) with a live "next 3 runs" preview; an advanced toggle exposes the raw cron expression.

Parameters

Behavior

Activation computes the next fire time; a database-backed scheduler claims due schedules and enqueues an execution (safe under multiple API replicas — each occurrence fires exactly once). Each run's trigger item is:

{ "fired_at": "2026-07-11T09:00:00+00:00", "cron_expr": "0 9 * * 1-5", "timezone": "UTC" }

Accepted cron syntax (validated at activation, never at runtime):

• 5-field standard: */10 * * * *, 0 9 * * 1-5
• 6-field with a trailing seconds field: * * * * * */15
• macros: @hourly, @daily, @weekly, @monthly, @yearly

Quirks & tips

• Missed occurrences are not replayed. If the instance was down for 3 hours, the schedule fires once on the next tick and re-anchors to now — no backfill burst. Design workflows to catch up from data ("fetch everything since the last run"), not from fire counts.
• Firing granularity is the scheduler's tick interval (seconds, not milliseconds) — a seconds-level cron fires near its boundary.
• The recurrence builder can't model 6-field or macro crons; those stay raw-only and round-trip untouched.
• Daylight-saving transitions follow the timezone: a 0 2 * * * job in a DST zone can skip or repeat wall-clock 2am on transition days — schedule critical jobs in UTC if that matters.
• If the workflow is deactivated or deleted, its schedule goes with it; an orphaned schedule row (crash mid-flight) is retired by the next tick instead of firing dead executions.

Related

• Webhook trigger — event-driven instead of time-driven.
• HTTP Request — the typical first node after a schedule (poll an API).