Temporal Schedules

When to use

Use this page while designing, implementing, operating, or troubleshooting scheduled and durable execution.

Behavior

• A non-empty schedule makes the runtime create a Temporal Schedule with the configured scheduleId.
• If that ID already exists, the runtime describes it and validates ServiceLib ownership, Workflow type, and Task Queue instead of creating a duplicate.
• The current create-or-validate path does not update the cron expression or policies of an existing Temporal Schedule.
• Each occurrence starts the endpoint execution type.
• The schedule callback receives backend: temporal.

What to enter

Cron Schedule and Temporal Schedule ID are different values. The first controls when an occurrence is created; the second identifies the durable server object.

• Cron Schedule example: */10 * * * *.
• Temporal Schedule ID example: example-automation-workflow-schedule.
• Keep the ID stable across restarts and deployments so the service finds the same server-side object.

When empty values are correct

A Temporal endpoint called through a Sink usually has no schedule of its own. In that case both fields remain empty.

• schedule: ""
• scheduleId: ""

Scheduled endpoint example

When the endpoint owns a durable schedule, fill both fields and keep timezone set to UTC.

• schedule: "*/10 * * * *"
• scheduleId: "example-automation-workflow-schedule"
• timezone: "UTC"

Schedule identity properties

Keep the durable ID stable across deployments.

Temporal Schedule configuration

schedule: "*/10 * * * *"
scheduleId: "example-automation-workflow-schedule"
timezone: UTC
overlapPolicy: Skip
missedRunPolicy: FireOnce
temporalExecutionType: Workflow

Related documentation