> ## Documentation Index > > Fetch the complete documentation index at: https://lithi.ai/llms.txt > > Use this file to discover all available pages before exploring further. --- title: Follow a job's status and events description: >- Read a job's current stage and its accepted, failed, abstained and missing counts, tell an accepted submission apart from completed work, and know which reading is canonical. route: /docs/compute/jobs/status-and-events page_id: docs-compute-jobs-status-and-events page_type: howTo content_layer: guided documentation surface_profile: guided_docs audience: Compute customers and integrators following work they have submitted voice: D reader_question: How do I tell what a running job has actually completed? primary_action: Read the job's current counts and stage source_locale: en-US source_status: APPROVED source_version: docs-compute-jobs-status-and-events-en-us-2026-09-05-v1 last_updated: '2026-09-05' robots: index claim_registry_pinned: true claim_registry_resync: "npm run governed:tsx -- scripts/build-compute-public-claim-registry.ts --write" --- ## Before you read a status You need the job identifier returned when the job was admitted, and a work key that can read jobs. Reading a status changes nothing about the job. ## What one reading tells you A status reading answers four things at once. - The job state: `ADMITTED`, `RUNNING`, `AWAITING_REVIEW`, `PARTIAL`, `CANCELLING`, `CANCELLED`, `FAILED` or `SUCCEEDED`. - The current stage state: `BLOCKED`, `READY`, `MATERIALIZING`, `RUNNING`, `VERIFYING`, `AGGREGATING`, `SUCCEEDED`, `PARTIAL`, `FAILED`, `SKIPPED` or `CANCELLED`. - The counts so far: accepted, failed, abstained and missing. - The observation time, `observed_at`, and the moment that reading stops being current, `valid_until`. Missing is the honest fourth number. It counts items you submitted that have not yet landed in any of the other three. It is not a fifth outcome, and it is never a silent success. ## An accepted submission is not completed work Acceptance at submission means your request passed validation and your approval was in place. It says nothing about output existing. The same word returns at item level, with a different meaning. An accepted item has produced output that passed the workflow's checks. Neither reading closes the job on its own. ## Which reading is canonical The result bundle's `result-manifest.json` is written last, and it is the only complete-bundle marker. It binds every file, count, schema, release and retention decision together. Part files appearing under `data/` never mean terminal success. Until the manifest exists, every count is the current view and nothing more. ## Follow a job without guessing Read the status again rather than inferring progress from elapsed time. Every reading is stamped, so two readings tell you whether anything moved. Your client reads one job with `lithi.status`. The command line can block until a batch settles with `lithi batch wait`. The job's event list gives you the ordered record, which is what you want when reconstructing a run after the fact. ## What a healthy reading looks like Stage states advance, and the four counts add up to the number of items you submitted. Missing falls toward zero as work settles. When the job reaches a terminal state, the manifest exists and the counts stop moving. That pairing is your signal to download. ## When a reading stops advancing Compare two readings taken minutes apart before you act. If neither the stage nor the counts moved, read the next action carried on the response envelope. Every non-success outcome carries a safe reason and a next action, and that action is the one to take. Do not resubmit to force progress. A resubmission under a new identity is new work and a second charge. See [what a stalled job means](/help/compute/job-stalled) when the next action is not clear, and [how a partial job is counted](/docs/compute/jobs/partial-completion) when the job ends `PARTIAL`.