Manage Temporal Schedules as Code from Kestra

Temporal schedules created through the CLI have a habit of becoming unreviewable tribal knowledge: nobody remembers who set the cron, and the only record is a terminal history. This blueprint moves the schedule definition into YAML that lives in Git: io.kestra.plugin.temporal.workflow.Schedule creates or, with overwrite: true, updates a schedule that starts a workflow type on a task queue at a cron cadence, and Slack announces every applied change with the schedule ID.

How it works

1. Flow inputs declare the whole schedule: schedule_id, cron_expression, workflow_type, task_queue, and the Temporal namespace. Changing the cadence is a one-line diff.
2. upsert_schedule (io.kestra.plugin.temporal.workflow.Schedule) connects to the frontend from TEMPORAL_ENDPOINT and applies the definition. With overwrite: true, rerunning the flow updates the existing schedule in place instead of failing, so the flow is idempotent and the YAML is the source of truth. The task returns the documented scheduleId output.
3. notify posts the applied scheduleId, cron, and workflow type to Slack, turning every schedule change into an announced event.
4. The errors block posts a distinct alert when the upsert fails, noting that the previous definition is still in effect.

What you get

• Temporal schedules defined in reviewable YAML rather than CLI one-offs.
• Idempotent apply semantics: rerun the flow as often as you like, the schedule converges to the declared state.
• An announcement in Slack for every schedule change, with the exact cron applied.
• A clear failure signal that distinguishes a failed change from a changed schedule.

Who it's for

• Platform teams treating Temporal schedules like any other infrastructure definition that belongs in Git.
• Engineers tired of reverse-engineering who changed a schedule and when.
• Teams standardizing schedule changes behind a pull request review instead of direct CLI access to production.

Why orchestrate this with Kestra

The schedule itself runs inside Temporal; what Kestra adds is everything around the change: typed inputs with defaults, secrets for the endpoint, an execution history showing who applied which definition and when, and a notification trail. Since cron and intervalSeconds are mutually exclusive on the task, the YAML also makes the chosen cadence style explicit and reviewable.

Prerequisites

• A reachable Temporal frontend and workers polling the target task queue with the workflow type registered.
• A Slack incoming webhook for confirmations and failure alerts.
• For Temporal Cloud, set the task's apiKey property; for mTLS clusters, provide caCert, clientCert, and clientKey.

Secrets

• TEMPORAL_ENDPOINT: Temporal frontend address in host:port format, for example temporal.example.com:7233.
• SLACK_WEBHOOK_URL: Slack incoming webhook URL.

Quick start

1. Add the two secrets to your Kestra namespace.
2. Set the inputs to a workflow type your workers register and a cron you want.
3. Execute the flow, confirm the schedule in the Temporal UI, then rerun with a changed cron and watch it update in place.

How to extend

• Pass workflow arguments to each tick with the task's args property, one JSON-encoded string per parameter.
• Switch from cron to fixed-interval cadence by replacing cron with intervalSeconds.
• Manage a whole fleet of schedules by wrapping the task in a ForEach over a list of schedule definitions.
• Verify the scheduled workflow actually completes by pairing this with the Temporal launch-and-wait blueprint.

Links

• Temporal plugin documentation
• Temporal schedules documentation