Scheduling
Workflows can run on a recurring schedule. Add a schedule object to the workflow definition.
Configuration
{
"name": "daily_reconciliation",
"definition": {
"schedule": {
"every": "1d",
"at": "02:00",
"timezone": "America/New_York"
},
"actions": [ ]
}
}
Schedule Fields
| Field | Type | Required | Description |
|---|---|---|---|
every |
string | Yes | Interval ā 30m, 1h, 6h, 1d, 7d |
at |
string | No | Time of day in 24h format ("02:00", "14:30"). Only applies when every is 1d or longer |
timezone |
string | No | IANA timezone ("America/New_York", "Europe/London", "Asia/Tokyo"). Defaults to UTC |
Examples
Daily at 2:00 AM Eastern:
{
"schedule": {
"every": "1d",
"at": "02:00",
"timezone": "America/New_York"
}
}
Every 6 hours:
{
"schedule": {
"every": "6h"
}
}
Every 30 minutes:
{
"schedule": {
"every": "30m"
}
}
Weekly (every 7 days) at midnight UTC:
{
"schedule": {
"every": "7d",
"at": "00:00"
}
}
How Scheduled Runs Work
Scheduled workflows execute with an empty @input unless a default input payload is configured. The @now context variable reflects the timestamp at execution time.
Each scheduled run creates a standard workflow run with its own run_id, full context, and audit trail ā identical to manually triggered runs.
If a scheduled run is still in progress when the next interval fires, the new run is queued. Runs do not overlap by default.
Scheduling + conditions. You can combine schedule with a top-level condition to create conditional scheduled workflows ā for example, a daily run that only proceeds if there are new records to process. The schedule fires the workflow, but the condition gates execution.