Job

A job is one execution of one benchmark on one device. A benchmark run over two models and three devices creates six jobs, each independent: its own status, its own result, its own log.

The job definition

A job definition is the template a job executes. It is self-contained, so anyone reading it can tell exactly what will happen on the device.

Part	What it declares
artifacts	Files to push before anything runs, each with a destination path on the device.
setup_steps	Commands to run after the files land (create a virtual environment, install dependencies, start a helper service).
script	The benchmark itself: command, working directory, environment, timeout.
output_path	Where the script must write its result file.
result_type	raw (keep the file) or structured (parse it into a result the platform can chart and compare).
teardown_steps	Commands that always run at the end, successful or not.
cleanup_policy	What of the pushed files, output and scratch paths is removed afterwards.
required_resources	Minimum CPU, memory, VRAM, disk, GPU count and accelerators the device must report.

For an ordinary benchmark you never write one of these and never pick one: the platform resolves the definition from the benchmark type and the device's platform and architecture. You write a definition when you are adding a new kind of benchmark to a deployment. Write a job definition covers the file in full.

What the platform does, and what your script does

The platform handles logistics: get the device into the right state, hand the script its inputs and an output path, run it, and collect what it produced. What happens inside the script is yours. The platform does not interpret your inference code, your timing, or how you talk to a local server. The one thing it requires is a result file at output_path.

States

QUEUED  ->  PUSHING_ARTIFACTS  ->  RUNNING_SETUP  ->  RUNNING  ->  RUNNING_TEARDOWN  ->  DONE
                                                                                     |-> FAILED
                                                                                     |-> PARTIAL
                                                                                     |-> INTERRUPTED

State	What is happening
QUEUED	Waiting for the device to finish its current job.
PUSHING_ARTIFACTS	Transferring files, skipping any whose checksum already matches on the device.
RUNNING_SETUP	Executing the setup steps in order.
RUNNING	Executing the script, streaming its output.
RUNNING_TEARDOWN	Executing the teardown steps.
DONE	Script succeeded, teardown succeeded, output collected.
FAILED	A step failed, or the declared output file was never written.
PARTIAL	The script succeeded and produced results, but teardown failed. The results are usable; the device is flagged dirty.
INTERRUPTED	The device disconnected mid-run. Teardown is retried when it reconnects, and a late result can still complete the job.

A job dispatched to a device that is already busy is requeued with backoff rather than failed, and gives up after ten minutes of trying. The per-device queue is visible on the device page.

Two guarantees worth knowing

Teardown always runs. Whether the script succeeded, failed, timed out or was cancelled, the teardown steps execute. That is what stops a failed run from leaving a service running, a GPU held, or a temporary directory filling the disk. If teardown itself fails, the device is flagged dirty and takes no further benchmark jobs until it is cleared.

A cancel stops the whole process tree. Every step runs as its own process group, so cancelling a job (or hitting the script timeout) stops what the step started and everything it spawned. A job the platform reports as cancelled is not still holding the device's memory.

Collecting the output

When the script exits, the platform fetches the file at output_path, stores it as an artifact, and links it to the job. Four outcomes are deliberately distinguished.

• Nothing at the declared path: the job fails, naming the path that was expected. Declaring an output path and not writing it is a broken contract with the platform, even when the script exited zero.
• A file that is not a result envelope: the job completes with a diagnostic, and the raw file stays attached. The format was the script's own choice, and its exit code was its own verdict.
• A valid envelope: the job completes and the result is parsed, charted and comparable.
• The fetch failed for another reason (the device went away mid-transfer): the job completes and the failure is logged, because nothing was established about what is on the device.

Cleanup

After teardown, cleanup runs in a fixed order: your teardown steps first, then the pushed artifacts (unless the definition keeps them), then any custom paths, then the output path (only if the definition asks for it). The default removes pushed artifacts and keeps the output.

Definitions that push a large engine bundle usually keep it, because the checksum skip makes the next run fast only if the file is still there.

Where you see it

Web UI

Jobs in the sidebar lists every job in the project. A device's Jobs tab lists what ran on that device, and a benchmark run's Details tab lists the jobs that run fanned out into.

CLI

clika-rt jobs list
clika-rt jobs get <id>
clika-rt apply -f job.yaml     # kind: Job, for a definition-based dispatch

Claude

Ask Claude:

Did any job fail on my devices today, and what did it say?

That reaches get_jobs and get_jobs_id, whose payload carries the failing step and the tail of what the script printed.

Related pages

• Benchmark: what creates jobs.
• Device: where they run.
• Write a job definition.