Skip to main content
Live. This area is documented as current, user-reliable behavior.

​
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

1
Open the project settings and add a scheduled job with a name, a command, and a schedule.
2
The platform runs the command in a one-off container from your active deployment image when the job is due.
3
Each run records the last run time, the next run time, and the exit code or error.
4
Disable or edit a job at any time; disabled jobs do not run.

​
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

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

​
Common failures

  • 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.

Worker and background processes

Run a project as a background process type (worker, queue, scheduler, reverb) instead of a public web service.

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.

Builds, deployments, and logs

Understand the project execution lifecycle: build output, deploy state, rollback behavior, and where to inspect logs.