> ## Documentation Index
>
> Fetch the complete documentation index at: https://lithi.ai/llms.txt
>
> Use this file to discover all available pages before exploring further.

---
title: Create a schedule
description: >-
  Write a schedule in the released trigger dialect, set the time zone, overlap, misfire and
  catch-up rules, then review the plan before you activate it.
route: /docs/compute/automation/schedules
page_id: docs-compute-automation-schedules
page_type: howTo
content_layer: guided documentation
surface_profile: guided_docs
audience: Administrators putting a proven workflow on a recurring trigger
voice: D
reader_question: How do I make a workflow run on a recurring schedule I can trust?
primary_action: Start work from an event instead
source_locale: en-US
source_status: APPROVED
source_version: docs-compute-automation-schedules-en-us-2026-09-05-v1
last_updated: '2026-09-05'
robots: index
claim_registry_pinned: true
claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write"
---

## Before you start

You need an administration credential, one workflow you have already run by hand, and a scoped automation identity for it to run as.

Run the workflow manually first. A schedule repeats whatever you gave it, including a request that was wrong in a way nobody noticed.

## Write the trigger in the released dialect

Schedules accept one released trigger dialect. Describe the schedules family to read the current dialect, the fields it accepts and the release it belongs to.

Do not port an expression from another product and assume it parses. A dialect that looks familiar can differ on ranges, step values and the meaning of the last field.

If the dialect cannot express what you need, say so in a simpler trigger and split the work into two schedules. A trigger you can read aloud is a trigger you can review.

## Decide the six behaviors that bite later

Set all six explicitly. A value you leave unstated is still a decision, made by the default rather than by you.

1. **Time zone.** Name the zone the business cares about, not the zone your laptop is in.
2. **Daylight saving.** On a transition day a wall-clock time can vanish or happen twice. Declare whether a missing time is skipped or shifted, and whether a repeated time runs once or twice.
3. **Overlap.** Decide whether a new occurrence may start while the previous one is still running, or must wait, or must be dropped.
4. **Misfire.** Decide what happens when an occurrence could not start on time, and how late is too late to start at all.
5. **Catch-up.** Decide whether occurrences missed during a pause or an outage run afterwards, and how many.
6. **Maximum runs.** Set a ceiling on total occurrences. An unbounded schedule is the one that surprises your invoice.

Overlap and catch-up interact. Catch-up with overlap allowed can start several occurrences at once, which is rarely what a finance owner expects.

## Review the plan before you activate

Plan the change, read the plan, then apply it. The plan states the resolved trigger, the identity it runs as, the profile values and the bound you are accepting.

Read the resolved next occurrence times in the plan, not the expression you wrote. The resolved times are what will actually happen.

Approve only after the bound looks like something you would sign for a month of unattended runs.

## Confirm success

Read the schedule back after the apply. The read-back is the current state; the apply response only says your request was accepted.

Check three things on the read-back. The state is active, the next occurrence times match your intent, and the identity is the one you meant.

Then watch the first real occurrence. Its events show admission, the fresh quote and the job it created.

## When an occurrence does not run

A due occurrence can still be refused, and the refusal names why and what to do next. Read the reason before changing the trigger.

- A budget refusal means your spend authority is exhausted, not that the schedule is broken. Raise or renew the ceiling.
- A capacity refusal is about this moment. The next occurrence is unaffected.
- An admission refusal about the request itself means the schedule needs a new plan, because the workflow or its inputs moved.

If an expected occurrence is simply absent, check the pause state and the catch-up rule first. See [why a scheduled run did not happen](/help/compute/schedule-missed) when the events do not explain it.

[Start work from an event instead](/docs/compute/automation/event-triggers)
