Skip to main content
A job is a single execution of a user-supplied command inside a one-off container built from the currently-running service. The container uses the same image, environment variables, and resources as the service’s live deployment; only the command is different. Jobs are the remote equivalent of specific exec. Where specific exec runs a one-off command against your local dev environment, a job runs against the deployed service in production (or any other environment). Use them for ad-hoc, on-demand work such as:
  • One-off data backfills or corrections.
  • Reconciling state, purging a cache, or replaying a queue.
  • Running a debugging or diagnostic script against production data.
Don’t use jobs for database migrations. Migrations should run in a pre_deploy hook so they’re tied to the deployment lifecycle: the hook runs before the new service version starts, and if it fails, the deployment is aborted before any traffic reaches the new code. Jobs are decoupled from deployments and have no such safety net.

​
Running a job

Open the dashboard, navigate to a service, and open the Jobs tab. Click Run job, fill in an optional name and a command, and submit. You are redirected to the job’s detail page, where you can watch its state and stream logs in real time. The command runs in a shell, so pipes and && work. Because the job is built from the service’s live deployment, it always sees the same secrets, configs, and resource bindings as the running service. There is no drift between what the service runs with and what the job runs with. Re-running a previous job pre-fills the modal with its name and command, convenient for replaying a task after fixing a bug.

​
Lifecycle

A job transitions through the following states:
  1. pending - the job has been recorded.
  2. queued - the job’s workflow has been started.
  3. running - the job container is running.
  4. One of:
    • succeeded - the command exited with code 0.
    • failed - the command exited with a non-zero code, or the underlying infrastructure rejected the job.
    • cancelled - the job was cancelled via the dashboard before it finished.

​
Caveats

  • The service must be deployed. A job builds its container from the service’s live deployment; if the service has never been deployed, the job fails with a clear error.
  • No retries on failure. If the command exits non-zero, the job is marked failed. Start a new job (or re-run) to try again.
  • Single container only. Sidecars and init containers are not replicated - only the primary container runs.
  • Concurrent jobs are allowed. Multiple jobs can run at the same time against the same service; be mindful of shared state.
  • Volume contention. If the service mounts a single-writer volume and runs on different underlying hardware than the job, the job can fail to schedule.
  • Job records are cleaned up one hour after completion. Logs remain queryable for the standard retention window.