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

# Schedules and time zones

> A schedule decides when run requests become due. It does not execute SQL itself or guarantee immediate worker availability.

How-to guideApplies to: Unified engine deployments

A schedule decides when run requests become due. It does not execute SQL itself or guarantee immediate worker availability.

## Choose a schedule

| Policy | Behavior | Example use |
| - | - | - |
| Manual | Run only when explicitly requested. | Develop and verify a workflow. |
| Immediately | Request one run after the workload is saved. | Submit one saved workflow for execution. |
| At | Request one run at a timestamp. | A one-time report. |
| Interval | Repeat from an anchor at fixed intervals. | Refresh every five minutes. |
| Cron | Repeat at calendar boundaries in a chosen time zone. | Process each day at midnight. |

Saving an Immediately workload or an already-due schedule can create work. Keep tutorials Manual until you deliberately enable scheduling.

## Schedule the orders example

1. Open [Your first workload](https://docs.e6data.com/transformation/workloads/first-workload.md) and verify one manual run.
2. Edit its schedule. Choose Fixed interval and enter 300 seconds with your chosen start time.
3. Choose Wait for overlap and Run once for missed runs.
4. Save, then inspect the next due time.
5. After a due boundary, confirm a scheduled run exists and reaches a final state.

The inline data stays unchanged, so each successful run computes six orders and sales of 140. Pause the schedule after checking it.

## Use cron deliberately

Laminar cron expressions include a seconds field. These examples use six fields:

| Expression | Meaning |
| - | - |
| `0 */5 * * * *` | Every five minutes, at second zero. |
| `0 0 * * * *` | Every hour. |
| `0 0 0 * * *` | Every day at midnight. |
| `0 0 9 * * MON-FRI` | Weekdays at 09:00. |

Set a named schedule time zone such as `UTC` or `Asia/Kolkata`. Validate the expression and inspect the next due time. Do not paste a five-field expression from another scheduler and assume the meaning is unchanged.

## Separate three clocks

| Clock | Purpose |
| - | - |
| Schedule time zone | Determines calendar boundaries for cron. |
| SQL time zone | Interprets timestamp values inside task SQL. |
| Browser local time | Displays or enters local date/time fields in the editor. |

UTC is useful for the first examples. Calendar schedules in zones with daylight-saving changes can have different elapsed durations between boundaries. If elapsed duration matters, choose an interval or inspect the actual window bounds rather than assuming every day is 24 hours.

## Pause and resume

Pause blocks new runs, including manual starts, while active runs continue. Resume allows new work again. The missed-run policy determines catch-up behavior. Inspect the next due time and run history after resuming.

Cancelling one active run does not pause its schedule. A Manual, paused, completed, cancelled, or deleted workload can have no next due time.

## Separate due time from data time

A run due at midnight might start later because of overlap or capacity. It should still process its intended period. Enable [Data windows](https://docs.e6data.com/transformation/workloads/data-windows.md) and use their bindings explicitly in SQL.

See [Overlap, missed runs, and queues](https://docs.e6data.com/transformation/workloads/concurrency.md) for backlog behavior, and [Backfills](https://docs.e6data.com/transformation/workloads/backfills.md) for deliberate historical processing.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.