Schedules run a saved message operation once at an exact date/time or repeatedly using UTC cron. Open Schedules from the System area of the navigation.
For how scheduled jobs execute (asynchronously, in the worker), see Jobs and execution reports.
Creating a schedule
Schedules are created from the operation wizards, not from the Schedules screen directly. In the Resubmission, Move, or Delete wizard, choose to schedule the operation instead of running it now. You provide:
- Schedule name and an optional Description.
- Run once at — select a future date and time in your browser-local time zone. The preview shows the exact instant, including the selected year. The wizard creates a One-time schedule.
In production, provide a Change reference for every scheduled operation, including resubmit; move/delete also require a Reason. The resubmission wizard’s maximum-rate field is ignored for scheduled work as well as immediate work; it is not a downstream rate guarantee.
The profile time zone controls displayed timestamps (UTC by default), but does not change browser-local one-time inputs or UTC cron. See profile time zone.
A one-time schedule is disabled and consumed atomically when the worker claims it, before job creation. It never recurs, including after a failed attempt or worker restart. If a failure prevents job creation, inspect execution history and create a new schedule after resolving the cause. A crash after claiming can leave the attempt without a job; the scheduler does not automatically rearm it. A created job retains the normal worker retry behavior without creating another schedule run.
Recurring schedules are available through the API using schedule_type: "cron" and a five-field
schedule_expression (for example, 0 2 * * * runs daily at 02:00 UTC). The wizard creates one-time
schedules only; editing does not change their mode.
The operation’s target environment, queue, and filters are captured from the wizard.
Managing schedules
The Schedules list shows each schedule with its mode, Operation, Last run, Next run, and status (Enabled / Disabled). You can:
- Filter by name/description, operation type, or enabled state.
- Edit an unconsumed schedule to change its name, description, and exact one-time date/time or recurring UTC cron expression. The editor identifies the mode.
- Enable or disable a schedule. Disabled schedules are retained but do not fire. Consumed or expired one-time schedules cannot be enabled again; create a new schedule instead.
- Delete a schedule (a confirmation dialog asks you to confirm). Deleting removes future runs; it does not affect jobs that already ran.
Execution history
Select a schedule’s Executions action to open its Execution history. Each execution records:
- Triggered — when the schedule fired.
- Status and counts — messages Matched, Processed, Succeeded, Failed.
- Error — hover the error indicator for the failure detail when a run fails.
A successful trigger creates a normal asynchronous job, so you can also follow it from the Jobs screen.
Ownership, access and expired references
Creating a schedule assigns its execution identity to the creator. Editing or enabling it transfers execution ownership to that manager; disabling does not. The original creator remains in the audit history. Workers use the current owner’s active status and scoped permissions at each run. Already-created jobs keep their original submitting identity.
A template with explicit message references may expire before its scheduled time. Expired references fail the execution before a job is created. Use criteria-based selections for recurring or distant schedules so each run finds fresh references. Content-bearing criteria require content-read permission as well as the operation permission. The normal bulk limit still applies.
The default schedule tick is 60 seconds, so a configured instant is a due time rather than a guarantee of exact execution time. Worker outages and queue backlog can delay it. Disabling/deleting a schedule prevents future submissions; cancel existing jobs separately. Restoring a database can restore pending schedules, so reconcile broker outcomes before restarting workers.