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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/jobs/).

## 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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/getting-started/sign-in-and-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](https://portal.cjcit.io/knowledge-base/message_ops/1.7/usage/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.