# Queue & Runtime Expectations

Submitted jobs queue until compute capacity is free, then run to a terminal status. This page covers status transitions, queue timing, priority, ETA signals, and runtime caps.

## How Jobs Move Through the System

Every job transitions through these statuses:

- **pending / queued**: waiting for available compute capacity
- **running**: SimulationCraft is executing
- **completed / failed / cancelled / timed_out**: terminal state,
  job is done

Track a job's current state in real time via
`GET /simc/jobs/{id}/status`. Poll until `status` is one of the
terminal values: `completed`, `failed`, `cancelled`, or `timed_out`.

## Queue Timing

Queue wait depends on current system load. The target is for `standard` jobs to start within a few minutes of submission.

Jobs are not allowed to wait indefinitely. If a job ages past its
queue timeout it fails with `queue_timeout`, meaning it never
started rather than ran and failed. It is safe to resubmit.

You can set a per-job queue timeout via `runtime.maxQueueSeconds` at
submission. The value must be a positive integer and cannot exceed your
account limit. If omitted, your account's default queue timeout
applies. Your current queue cap is visible via `GET /simc/usage`.

## Priority

Each job is submitted at one of two priority levels: `standard` or `high`. Higher priority is picked first; jobs at the same priority run in submission order. Default is `standard`.

| Priority   | Order | Billing                                        |
| ---------- | ----- | ---------------------------------------------- |
| `high`     | First | Standard rate plus a flat per-job priority fee |
| `standard` | Next  | Standard rate                                  |

The fee is returned as `limits.priorityFeeCredits.high` from `GET /simc/usage`. If a `high`-priority submission is rejected with `code: "insufficient_credits_liability"`, the response also includes the applicable `priorityFeeCredits` so you can decide whether to add credits or fall back to `standard`.

## ETA Signals

The status endpoint exposes `queue.estimatedStartSeconds`, a
best-effort countdown to when the job is expected to start.

## Runtime Limits

Every job runs under a maximum runtime cap. Jobs exceeding the limit
are marked `timed_out`. Your current limit is visible via
`GET /simc/usage` in `limits.maxRuntimeSeconds`. You can request a
specific cap per job via `runtime.maxRuntimeSeconds` at submission,
subject to your account limits.

---

_HTML version: https://simmit.com/docs/api/queue-expectations · Full docs index: https://simmit.com/llms.txt_