> ## Documentation Index
> Fetch the complete documentation index at: https://docs.asteroid.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Schedules
> Run a workflow on a repeating cron schedule, or book a single run for a future time.
A **schedule** runs a workflow without anyone pressing a button. Open a workflow and go to the
**Schedule** tab. It has two views.
A cron expression that fires again and again
Single runs booked for one future time
***
## Add a recurring schedule
Open the **Recurring Schedule** view and select **Create Schedule**. A workflow can hold several
schedules at once.
| Field | What it does |
| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Name** | Identifies the schedule on its card. |
| **Workflow version** | The version each execution uses. Pick **Published version** to follow whatever is published, or pin a version number. Only published versions can be scheduled. |
| **Agent profile or pool** | Optional. A single profile serves every execution. A pool picks a different profile per execution. |
| **Inputs** | Fixed values for the workflow's declared inputs. Every execution receives the same values. |
| **Schedule** | The cron expression. Pick a preset, build one in the editor, or type one. |
| **Run when enabled** | Runs at once when you switch the schedule on, instead of waiting for the next tick. |
Save the schedule and it appears as a card. The card carries a switch that turns the schedule on and
off, and it shows the next execution time.
Cron expressions are read in **UTC**. A schedule set for 09:00 fires at 09:00 UTC, whatever your
local time is.
Turn a schedule off before you change its version or its profile. Those two fields are locked while
the schedule is enabled.
The card warns you when the schedule's saved inputs no longer match the version it runs. Republish
the workflow or edit the schedule's inputs to clear it.
### Cron presets
The editor offers presets. They cover intervals from every minute up to every 12 hours, and longer.
Build a custom expression in the same editor by picking minutes, hours and weekdays. The editor
prints the expression back in words, so you can check it.
***
## What a tick fires
A schedule works in one of two modes.
### One execution per tick
This is the default. Each tick starts one execution of the workflow. The execution uses the schedule's inputs, its
pinned version, and its profile or pool.
The execution appears in the workflow's **Executions** list like any other run, with `Scheduled` as its
runner. Filter for these runs with `triggerSource=schedule`:
```bash theme={null}
curl -G "https://odyssey.asteroid.ai/agents/v2/executions" \
-H "X-Asteroid-Agents-Api-Key: $ASTEROID_API_KEY" \
--data-urlencode "agentId=$AGENT_ID" \
--data-urlencode "triggerSource=schedule"
```
### A batch per tick
Point the schedule at a Google Sheet and each tick creates a whole
[batch](/operate/batches) instead of one execution.
The platform re-reads the tab on every tick, so the batch matches the rows that exist at that
moment. Add rows during the week and next week's run picks them up.
| Field | What it does |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Google Sheets URL** | The sheet to read. Include the tab's `gid` to target one tab. Without a `gid` the platform reads the first tab. A private sheet uses your connected Google account. |
| **Column mapping** | Maps a column header to the workflow input it fills. Unmapped columns are ignored. |
| **Skip a row when these are empty** | Inputs a row must supply. A row missing any of them is skipped for that tick, and the rest of the sheet still runs. Mark nothing and every non-empty row runs. |
| **Pacing** | How many rows may run at the same time. |
A new recurring batch paces by concurrency alone. It caps how many rows run at the same time, and each
time one finishes the next starts. Every batch from one schedule shares that one budget, so two
overlapping ticks cannot double the load.
The editor warns you when a schedule cannot keep up — when it queues rows faster than it can drain
them. Run it less often, raise the concurrency limit, or cut the sheet down.
***
## Book a single execution
For a one-off, use the workflow's **Run** panel. Set a date and time under **Schedule**, then start the
run. The time must be in the future.
The execution waits in the **Scheduled Executions** view until its time arrives.
***
## Scheduled executions
The **Scheduled Executions** view lists every execution the platform holds for this workflow. That covers
one-off bookings and every row of every batch.
| Status | Meaning |
| ------------------- | ------------------------------------------------ |
| `pending` | Waiting for its time to arrive. |
| `awaiting_capacity` | Waiting for a concurrency slot. |
| `batch_paused` | Held because its batch is paused. |
| `triggered` | The execution started. |
| `cancelled` | Cancelled before it started. |
| `failed` | Could not start at all, and will not be retried. |
Sort the list by scheduled time, and filter it by status or by batch. Each row has two actions:
**Cancel**, which stops it starting, and **Reschedule**, which moves it to a new time.
A row that reaches `triggered` becomes an ordinary execution, with its own ID, status, recording and
result. From that point it behaves like any other run. See
[Executions and statuses](/concepts/executions).
***
## Best practices
**Published version** follows your latest publish, which means a publish changes what runs. This is usually what you want, as it means that new updates are incorporated into your next executions.
Rows that run at the same time under one profile share one browser state and can cause side effects. A profile pool gives each row its browser session and optionally login details, which can be useful if the portal you're automating doesn't react well to having one set of credentials used 100 times concurrently. See [Agent profiles](/concepts/profiles).
Attach a webhook or a Slack notification so a failure reaches a
person. See [Webhooks and Slack](/operate/webhooks-and-slack).
***
## Next
Pacing, column mapping, and batch statuses
What an execution does once it starts
Get told when a unattended execution fails
What "published version" tracks