Scheduled jobs

Jobs run commands or saved Actions workflows on a schedule, once, on demand, or after an event. Find them under Jobs in self-hosted Openship and Openship Cloud.

Every run is recorded — when it last ran, whether it succeeded, how long it took, and its output.

Built-in jobs

Self-hosted installations also show the system jobs Openship runs for you. Cloud maintenance is managed privately by the platform; Cloud customers see their own command jobs and authorized backup schedules.

An instance administrator can change the schedule, enable/disable it, Run now, and see its run history. You can't delete a built-in job (it's part of Openship) — disable it instead.

Your own jobs

Need a nightly database dump, a cache warm, or a cleanup script? Create a custom job:

1. In Jobs, click New job.
2. Give it a name, pick the server it runs on, enter the command, and a schedule (cron).
3. Save. It runs on that schedule, and you can Run now any time.

While a job runs you can watch its live output, and every run is kept in history with its result.

Run a workflow

Choose Run workflow in the new-job form, or Schedule with Jobs from an Actions workflow. Select an enabled workflow with workflow_dispatch, fill its declared inputs, and choose a schedule or event. Runner selection, secrets and storage remain on the workflow; Jobs controls when it starts.

History and notifications use the original Actions run. Open that execution to see its dependency graph, step logs and cancellation controls. Success dependencies fire after the workflow completes and its worker cleanup finishes. Replayed timer or dependency deliveries reuse their execution identity. Disabling or revoking access to the workflow prevents new authorized execution.

See Openship Actions for runner setup, triggers and project deployment rules.

Choosing a Cloud server

Select an existing managed server to share its resources with your projects, or click Add a dedicated server to create a server with its own subscription. The same job form supports both. You can also select several servers to run the command on each one.

Jobs use the selected server's capacity and usage allowance. The server must be running and its subscription and balance must allow new work. A job does not provision or resume a server automatically. Run now opens the server's plan options if billing prevents execution; scheduled attempts record the failure in run history. Provision or resume a paid server from Servers when needed.

Commands execute on the server itself. To run a temporary container task, use docker run --rm <image> <command> on a server with Docker available. Jobs have the server's command privileges, so configuring or reading a job requires administration access to all its targets as well as Jobs permissions.

Schedules (cron), in plain terms

A schedule is a standard 5-field cron string:

┌───────── minute (0–59)
│ ┌─────── hour (0–23)
│ │ ┌───── day of month (1–31)
│ │ │ ┌─── month (1–12)
│ │ │ │ ┌─ day of week (0–6, Sun=0)
* * * * *

Openship validates the cron when you save and shows the next run time.

CLI

Use openship job (alias jobs) with your Cloud or self-hosted connection context:

openship job list
openship job create --name weekly-sync --server <server-id> \
  --command 'cd /srv/app && npm run db:sync' --cron '17 4 * * 1'
openship job get <key>
openship job update <key> --no-enabled
openship job update <key> --enabled --cron '0 3 * * *'
openship job run <key> --follow
openship job runs <key> --limit 10
openship job logs <run-id> --follow
openship job delete <key> --yes

Jobs also work with openship --native-config <file> job ... through the native SDK.

Use the job key from list or create, not its database ID. For a one-time job, pass --schedule once --at <ISO-timestamp>. For manual execution only, pass --schedule manual. Recurring jobs use --cron.

Both create and update accept --file <path> containing a JSON Jobs API body. Use it for workflowId and inputs, or env, secrets, serverIds, retry, timeoutMs, dependsOn, triggerEvents, or notifyConfig, or to supply the entire job configuration. Explicit flags override file values. Updates send only supplied fields. Keep files containing secrets private. The API encrypts secrets at rest.

--json returns API data without the envelope. Followed runs emit JSON events. Without --follow, run returns a custom run ID immediately. With --follow, the CLI waits for the outcome and exits nonzero on failure or an interrupted stream. Built-in jobs return their summary directly. logs without --follow shows stored output, or the full run record with --json.