Skip to content
Ownkube

Scheduled jobs

A job is a resource type that runs a container to completion and exits, instead of serving forever. Make it one-off for a migration or backfill, or give it a cron schedule for nightly cleanups, syncs and reports.

One-off

No schedule. Runs when you press Run now. Good for migrations, imports and anything you trigger and walk away from.

Scheduled

Runs on a cron expression in the time zone you choose. Good for periodic syncs, cleanups and report generation.

Create a job

Section titled “Create a job”

  1. Choose Job as the resource type

    In the create flow, pick Job. Name, project, environment and region work as for any deployment.

  2. Point at a source

    A repository and branch, or an image and tag. The same as a web app; see Builds and source.

  3. Set the command

    The command and arguments the container runs. Leave them empty to use the image’s own entrypoint.

  4. Decide one-off or scheduled

    Leave the cron expression empty for a one-off job. Set one to make it recurring, for example daily at 03:00:

    0 3 * * *

  5. Create

    A scheduled job fires on its next tick. A one-off job waits for Run now.

The Runs tab

Section titled “The Runs tab”

A job’s page has a Runs tab in place of the hostname and scaling sections of a web app.

  • Run history lists past and in-progress runs with their status, start time and duration.
  • Run now triggers a run outside the schedule, including for a suspended schedule.
  • Cancel stops an in-progress run.

Each run’s logs are on the Logs tab, filtered by run. From the terminal: okctl deploy job-runs list, trigger and cancel. Your coding agent can do the same through the MCP server.

What you configure

Section titled “What you configure”

Beyond the shared fields, a job’s Settings tab holds its schedule and execution controls. The Configuration reference lists every default and range.

  • Schedule: cron expression, time zone, whether overlapping runs are allowed, skipped or replaced, a start deadline, and how many successful and failed runs to keep.
  • Execution: what happens on failure, a retry limit, a run timeout, when to clean up finished runs, and how many parallel tasks and completions a run needs.
  • Resources and Variables work exactly as for a web app.

Limits

Section titled “Limits”
  • No port, no public hostname, no autoscaling, no sleep. A job is not a server.
  • A run is billed like any other container, per minute while it runs. Nothing bills between runs.
  • Schedules use the time zone you set, defaulting to UTC.
Configuration reference Every job field with its default and range.
Logs Read a run's output, live or after the fact.
Variables Pass configuration and secrets into the run.