Scheduled jobs

A scheduled job runs a container command on a cron schedule or when you select Run now. Each run has its own status, attempts, image digest, and logs. New jobs start paused so you can test the command before enabling the schedule.

Find your way around

Open the job in its project environment. The header shows the job name, enabled or paused state, and image. The summary below it shows Next run, Last run, Last duration, and Active runs.

A job uses run history rather than the application's deployment and revision workflow. There is no interactive job terminal in this screen.

Before you start

Have a project environment assigned to a cluster and a container image that its nodes can pull. Your role needs Manage workloads to create or edit a job and enable or pause its schedule. Manage deployments allows manual runs and cancellation. Protected environment variables and managed files require Manage secrets, and logs require View logs.

Choose an image and command that exit when the work is complete. Jobs have no application route or container-port editor.

Create a job

1. Open Workloads, then open your project.
2. Choose the intended environment in the environment selector beside the project name.
3. Select Add Service → Scheduled job.
4. Under Basics, enter Name and, optionally, Description. The project remains selected.
5. Under Image, enter Repository and Tag, then select Registry.
6. Under Schedule, enter Cron expression and select Timezone. Review the three dates shown under Next scheduled runs.
7. Under Execution policy, choose the timeout, retries, and overlap behavior.
8. Set Command and Arguments if the image defaults do not already perform the intended job. Add environment variables, resources, storage, and placement as needed.
9. Select Create scheduled job. The detail page opens with a paused badge.
10. Select Run now to test the saved job. Upvale opens Runs; inspect the run's Details and Logs.
11. When the result is correct, select Enable schedule. Check Next run in the summary.

Choose an image

Enter Repository and Tag separately. For a public Docker Hub image, choose public / anonymous. When selecting a saved registry connection, enter the repository relative to that connection's host: use acme/reports with a saved ghcr.io connection, not ghcr.io/acme/reports.

Moving tags such as latest are accepted. Each run records the immutable image digest it actually executes.

Set the command and arguments

Command overrides the image entrypoint. Use Add command item to add one array item per row. Leaving the command empty uses the image's entrypoint.

Arguments uses Add argument, with one argument per row. Upvale does not split a row on spaces or interpret it as a shell command. If you need shell syntax, invoke the shell explicitly and pass the script as an argument.

Working directory can be left blank to use the image default. Run as user accepts a user name or UID, optionally followed by a group name or GID, such as 1000:1000.

Try a command that prints one line

Use this small job to check that an image can be pulled and a command can complete:

Leave storage and environment variables empty. Select Create scheduled job, then Run now. When the container completes successfully, its output should contain scheduled job and its status should be succeeded. Leave the schedule paused unless you want this command to run every day at 02:00 UTC.

Set the schedule

The cron expression has exactly five fields:

minute hour day-of-month month day-of-week

Select the intended IANA Timezone, such as UTC or Europe/London. The schedule follows that timezone, including daylight saving changes. The initial selection follows your date/time preference, using the browser timezone when that preference is selected. Review Next scheduled runs before saving.

Missed scheduled occurrences are skipped; they are not replayed as catch-up work after scheduler downtime. A scheduled occurrence also has a limited start window: it must begin within 60 seconds of its requested time. This is separate from the execution timeout below.

Choose execution limits

The concurrency limit includes both scheduled and manual runs. A scheduled occurrence at the limit is recorded as skipped; it is not queued to run later. Run now reports a conflict if the limit is already occupied. A cancelled or timed-out execution can continue to occupy its slot until its runtime removal has been confirmed.

Use retryable commands when enabling retries: an earlier attempt may already have completed part of the work before failing. For jobs writing to the same local volume, keep overlapping runs forbidden unless the workload supports concurrent writers.

How a run works

1. The schedule becomes due, or you select Run now.
2. Upvale checks whether another execution is allowed by the overlap policy.
3. It captures the saved configuration for this run and resolves the image to a digest.
4. A temporary container runs on an eligible node.
5. Exit code 0 completes the attempt successfully. A failed attempt can be retried within the configured count and overall timeout.
6. Upvale records the result, captures the retained logs, and removes the run's temporary runtime.

A run is the whole execution request. An attempt is one try inside it. With two retries, one run can have up to three attempts. All attempts belong to the same history entry.

Configure environment, resources, and storage

Environment variables supports Add variable with a value or a stored secret source. The Editor view accepts one NAME=value per line and secret references such as TOKEN=[JOB_TOKEN]. The referenced secret must already exist and be available to the project. These controls require Manage secrets.

Resources provides these per-container settings:

The supported ulimits and their units are listed in Application resource limits. These settings limit the container; they do not reserve time on the schedule.

In Storage, select Volume mount, then enter Logical volume name and an absolute Container path. Named volumes persist across individual executions. Local volumes belong to one node, so select that node under Placement → Specific node when the job must reuse data stored there. A volume with the same name on a different node contains separate data.

File mount, available with Manage secrets, supplies a read-only configuration file. Set File name, Container file path, and File content. File content has a maximum of 500 KB; use secrets for credentials rather than embedding passwords or private keys in the file.

Placement options

A job does not require a public route to call another service. Use that service's internal address and port when it is reachable on the job's service network. For database work, put the appropriate database connection in an environment secret.

See Storage for persistent volumes and files. Volumes are scoped to the service; giving a job's volume the same logical name as an application's volume does not automatically share their data.

Edit, pause, or run a job

Open the Job tab to edit configuration and select Save changes. The controls for Run now and schedule changes are disabled while the form has unsaved changes; save them or select Discard changes first.

Saving updates the definition used for future runs. A run already queued keeps its captured configuration. Job changes do not require an application-style deployment action.

• Run now starts a manual run from the saved job definition, including when the schedule is paused.
• Enable schedule allows future scheduled runs.
• Pause schedule prevents future scheduled runs. It does not cancel a run already in progress.
• Cancel run stops an active run. Enter an optional Reason (optional) and confirm Cancel run. The run remains in history as cancelled.

For protected jobs, a role without Manage secrets may still be able to pause a schedule or cancel a run, while editing, enabling, and starting that configuration remain blocked.

Inspect run history and logs

Open Runs for Run history. Filter using All statuses and All triggers, or select Scheduled or Manual. History is paginated in groups of 50 runs.

Select Details on a run to inspect its status, failure message, and attempts. Each attempt shows its node, container, exit code, duration, and log state. Common run states include queued, starting, running, retrying, succeeded, failed, timed out, cancelled, and skipped.

Select Logs for a run, or open the Logs tab:

1. Select the Run.
2. Choose All attempts or one Attempt.
3. Choose Lines: Last 100, Last 500, Last 1,000, or Last 5,000.
4. Set Stream to All output, stdout, or stderr.
5. Search within the available live or archived output.

Active runs show live output. After a run ends, the view may show Finalizing archived logs while capture finishes; it refreshes automatically. Download full log becomes available when an archive exists and downloads the retained run log rather than just the current on-screen filter.

Run metadata and archived logs are retained for 30 days. The archive keeps at most the latest 5,000 lines and 10 MiB of log data, including log metadata, across all attempts of a run. Output beyond that budget is truncated, so a full-log download cannot restore discarded output. A capture interrupted by transport failure can also be incomplete.

Run-status reference

Trigger tells you whether the run came from the schedule or Run now. Scheduled for is the intended time; Started is when execution began. Duration is measured from the actual start.

A log state of pending means capture has not finished. Archived shows its retained line count and size. Unavailable means Upvale has no archived output for that attempt. Truncated means part of the output exceeded the archive limit.

Remove a scheduled job

1. Pause its schedule.
2. Cancel active runs and wait for their runtime cleanup.
3. Open Job → Danger zone → Remove job.
4. Enter the job name and confirm. Name matching is case-insensitive.

Removing a job also removes its history. Download any retained logs you need first.

If an active run is stranded and no manager is online, the page can offer Remove scheduled job record only. This marks the run cancelled in Upvale but cannot stop a container on an unreachable server. The dialog requires you to acknowledge that runtime resources may remain.

Common problems