Kubernetes Batch Status Management

Kubernetes Batch Status Management is the practice of reading, interpreting, and acting on the .status subresource exposed by Kubernetes batch workloads — Jobs and CronJobs — which together form the authoritative, continuously updated record of how a batch workload is actually progressing, distinct from the desired state declared in .spec. Because batch workloads are finite and their state changes meaningfully over their lifetime (active, succeeded, failed, complete), correctly reading status is the primary mechanism by which operators, automation, and downstream systems know what a batch workload has actually done, rather than merely what it was asked to do.

Status management spans two related objects with different status shapes: the Job's own .status, which reflects a single execution's progress, and the CronJob's .status, which reflects the state of the recurring schedule itself and its most recent activity.

Job Status Fields

Counters

• .status.active: number of currently running Pods.
• .status.succeeded: number of Pods that have completed successfully.
• .status.failed: number of Pods that have failed (and counted against the retry budget).
• .status.completedIndexes (Indexed Jobs only): a compressed string representation of which completion indices have succeeded, such as "0-3,5,7".
• .status.failedIndexes (Indexed Jobs with backoffLimitPerIndex): indices that have exhausted their individual retry budget.

Timestamps

• .status.startTime: when the Job controller began actively working on the Job.
• .status.completionTime: when the Job satisfied its completion criteria (set only once Complete is reached).

Conditions

.status.conditions is a list of typed condition objects (type, status, reason, message, lastTransitionTime, lastProbeTime), with the most important types being Complete, Failed, Suspended, and FailureTarget. Reading conditions rather than inferring state purely from the numeric counters is the more robust approach, since conditions explicitly encode terminal outcomes and their reasons (BackoffLimitExceeded, DeadlineExceeded), while counters alone cannot distinguish "still running" from "finished long ago" without also checking completionTime.

kubectl get job codartium-batch-import -o jsonpath='{.status}'

CronJob Status Fields

lastScheduleTime

Records the most recent time the CronJob controller successfully created a Job for a scheduled tick. This is the primary field used to detect whether a CronJob's schedule is being honored — comparing this timestamp against the expected interval reveals whether ticks are being missed.

lastSuccessfulTime

Records the most recent time a Job created by the CronJob reached the Complete condition, which can lag behind lastScheduleTime if recent runs have been failing even though new Jobs are still being scheduled correctly.

active

A list of object references to currently running Jobs created by the CronJob, used internally (and by concurrencyPolicy) to determine whether an overlapping run exists.

kubectl get cronjob codartium-nightly-report -o jsonpath='{.status.lastScheduleTime} {.status.lastSuccessfulTime}'

Building Automation on Status

Polling vs Watching

kubectl wait --for=condition=complete and equivalent API watch calls are preferred over manual polling loops, since they rely on the Kubernetes watch mechanism to be notified of status changes efficiently rather than repeatedly issuing full GET requests against the API server.

kubectl wait --for=condition=complete job/codartium-batch-import --timeout=600s

Distinguishing "Still Running" from "Terminal"

Correct automation must check for the absence of both Complete and Failed conditions to conclude a Job is still in progress, rather than assuming any non-Complete state implies failure. A Job with neither condition present and .status.active greater than zero is straightforwardly still running.

Combining Status with Events

kubectl describe job surfaces both status fields and the underlying Kubernetes events (Pod creation, scheduling failures, backoff triggers) in one view, which is typically the fastest way for a human operator to understand not just the current status but the sequence of events that led to it.

kubectl describe job codartium-batch-import
kubectl get events --field-selector involvedObject.name=codartium-batch-import

Example: A Status-Driven Health Check Script

#!/usr/bin/env bash
STATUS=$(kubectl get job codartium-batch-import -o jsonpath='{.status.conditions[?(@.type=="Complete")].status}')
if [ "$STATUS" = "True" ]; then
  echo "Job completed successfully"
else
  FAILED=$(kubectl get job codartium-batch-import -o jsonpath='{.status.conditions[?(@.type=="Failed")].status}')
  if [ "$FAILED" = "True" ]; then
    echo "Job failed"
    exit 1
  fi
  echo "Job still running"
fi