Complete field-by-field reference for the CronWorkflow resource: schedule expressions, concurrency policies, history limits, and the embedded WorkflowSpec.
Use this file to discover all available pages before exploring further.
The CronWorkflow resource wraps a standard WorkflowSpec with a cron schedule, giving you periodic, time-driven workflow execution without any external job scheduler. The engine stores an immutable snapshot of the definition at submit time and re-submits a fresh WorkflowRun on each schedule tick. CronWorkflow operations require a cron.Scheduler to be injected via WithCronScheduler; calling them without one returns ErrNotSupported.
Unique name for this cron workflow definition. Must follow DNS-1123 label
rules: lowercase alphanumeric characters or hyphens, must start and end
with an alphanumeric character, maximum 63 characters.
IANA timezone string used to interpret the cron schedule (e.g.
"America/New_York", "Europe/Berlin", "UTC"). When omitted the
scheduler uses UTC. Invalid timezone strings fail validation.
RFC3339 datetime string. Triggers are suppressed before this time. When
omitted the schedule is active immediately on submit.Example: "2026-01-01T00:00:00Z"
RFC3339 datetime string. Triggers are suppressed after this time. Must
be strictly after startAt when both are set. When omitted the schedule
runs indefinitely.Example: "2026-12-31T23:59:59Z"
Maximum number of seconds past the scheduled time within which a missed
trigger is still eligible to fire. A trigger is considered missed when
the engine was down or suspended during the scheduled tick.Must be greater than 0 when set. null (or omitted) means no deadline —
missed triggers are always back-filled.
Maximum number of successful WorkflowRun records to retain. Once the
limit is reached the oldest successful runs are garbage-collected.
0 means retain all successful runs.
Maximum number of failed WorkflowRun records to retain. Once the limit
is reached the oldest failed runs are garbage-collected.
0 means retain all failed runs.
When true, no new triggers are fired. Existing active runs continue to
completion. Use UpdateCronWorkflow to toggle this field without
deleting and re-submitting the definition. This is the recommended
mechanism for pausing a scheduled workflow.
The embedded WorkflowSpec that describes what runs on each trigger.
This field is validated exactly as if it were spec on a standalone
Workflow resource. All template types, arguments, hooks, and timeout
fields are supported.
workflowSpec is immutable after submit. Attempting to change it
via UpdateCronWorkflow returns ErrValidation. To change the workflow
logic, delete the existing CronWorkflow and submit a new one.
See the Workflow Schema reference for the
complete WorkflowSpec field documentation. The mutable scheduling fields
(schedule, timezone, concurrencyPolicy, suspend, etc.) can be
updated freely via UpdateCronWorkflow.
The following example is taken directly from the engine’s integration test suite
(28-cron-basic.json). It fires every hour on the hour and runs a single echo
task.
Use Engine.UpdateCronWorkflow to change scheduling parameters (schedule,
timezone, concurrencyPolicy, startAt, endAt, suspend,
startingDeadlineSeconds, history limits) without re-submitting. The engine
re-registers the schedule with the cron backend automatically.
WorkflowRun records created by a CronWorkflow are not cascade-deleted
when the CronWorkflow is deleted via DeleteCronWorkflow. Existing run history
is preserved. Only future triggers are stopped.