Scheduled jobs

Jobs run commands on your servers, on a schedule, once, on demand, or after an event. Find them under Jobs in self-hosted GramCode and GramCode 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 GramCode 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 GramCode) — 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.

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)
* * * * *

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