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

# Scheduled jobs (cron)

> Run a command from your deployed image on a recurring standard-cron schedule, with run history and exit-code tracking.

<Tip>
  **Live.** This area is documented as current, user-reliable behavior.
</Tip>

## Goal

Schedule recurring commands (migrations, cleanups, reports) against your project’s active deployment image.

## Prerequisites

* An active deployment with a built image
* The command you want to run inside that image

## Workflow

<Steps>
  <Step>
    Open the project settings and add a scheduled job with a name, a command, and a schedule.
  </Step>

  <Step>
    The platform runs the command in a one-off container from your active deployment image when the job is due.
  </Step>

  <Step>
    Each run records the last run time, the next run time, and the exit code or error.
  </Step>

  <Step>
    Disable or edit a job at any time; disabled jobs do not run.
  </Step>
</Steps>

## How a scheduled job runs

A scheduled job is a recurring one-off command, not a persistent process. When due, the platform launches a fresh container from your project’s active deployment image and runs the command (with a per-run time limit). It is the same execution model as a one-off command, on a schedule.

For Functions projects, a scheduled command that targets a function is enqueued through the Functions runtime instead of running a container command.

## Supported schedule formats

Schedules use standard five-field cron syntax (minute, hour, day-of-month, month, day-of-week), so arbitrary expressions work — specific minutes and hours, day-of-week, day-of-month, month ranges, lists, and step values.

* Standard cron: e.g. 0 9 \* \* 1 (09:00 every Monday), 30 6 1 \* \* (06:30 on the 1st of each month), \*/15 \* \* \* \* (every 15 minutes).
* Descriptors: @hourly, @daily, @weekly, @monthly, @yearly (and @midnight).
* Intervals: @every \<duration>, e.g. @every 30m or @every 2h.

## Timing and time zone

Cron expressions are evaluated in UTC and fire at their true wall-clock boundaries — @daily runs at 00:00 UTC, and 0 9 \* \* 1 runs at 09:00 UTC on Mondays.

The scheduler polls about once a minute, so a job fires within roughly a minute of its scheduled time (minute resolution). Sub-minute precision is not guaranteed.

## Requirements and failures

* A job needs an active deployment with an image; without one, the run is recorded as failed.
* A non-zero exit code is captured so you can see failures in the job’s history.
* Name, command, and a supported schedule are all required when creating a job.

## Expected result

<Check>
  Your command runs automatically on the chosen cadence, with visible run history and exit codes.
</Check>

## Common failures

<Warning>
  * invalid schedule: the expression is not valid standard cron, a descriptor, or an @every interval — fix the syntax.
  * active deployment has no image: deploy the project successfully before expecting scheduled runs.
</Warning>

## Related guides

<CardGroup cols={2}>
  <Card title="Worker and background processes" href="/projects/worker-processes">
    Run a project as a background process type (worker, queue, scheduler, reverb) instead of a public web service.
  </Card>

  <Card title="StackShift Functions" href="/projects/stackshift-functions">
    Deploy Node.js serverless-style functions from an `api/` directory with HTTP handlers, async invokes, queue triggers, schedules, retries, replayable runs, and instant HTTPS routing.
  </Card>

  <Card title="Builds, deployments, and logs" href="/projects/builds-deployments-and-logs">
    Understand the project execution lifecycle: build output, deploy state, rollback behavior, and where to inspect logs.
  </Card>
</CardGroup>