Skip to main content
Jobs run pods to completion for batch processing tasks. Unlike Deployments that run continuously, Jobs ensure a specified number of pods successfully terminate. They are ideal for one-time tasks, data processing, and batch operations.

​
Key Concepts

Job

A controller that creates pods and ensures a specified number complete successfully.

Completions

The number of pods that must complete successfully before the Job is done.

Parallelism

The maximum number of pods that can run simultaneously.

Backoff Limit

The number of retries before marking the Job as failed.

​
Required Permissions

ActionPermission
View jobsiam:project:infrastructure:kubernetes:read
Create jobiam:project:infrastructure:kubernetes:write
Edit jobiam:project:infrastructure:kubernetes:write
Delete jobiam:project:infrastructure:kubernetes:delete

​
Job Status Values

StatusDescription
CompleteAll required completions succeeded
FailedJob exceeded backoff limit or deadline
RunningPods are actively running
PendingJob created but no pods started yet

​
Job Metrics

MetricDescription
CompletionsTarget number of successful pods (e.g., 3/5)
SucceededNumber of pods that completed successfully
FailedNumber of pods that failed
ActiveNumber of pods currently running
DurationTime from Job start to completion

​
How to View Jobs

1

Select Cluster

Choose a cluster from the cluster dropdown.
2

Select Namespace

Choose a namespace or select “all” to view Jobs across all namespaces.
3

Filter and Search

Use the search box to find Jobs by name, namespace, or status. Filter by status (Complete, Failed, Running, Pending).

​
How to View Job Details

1

Find the Job

Locate the Job in the list.
2

Click Job Name

Click on the Job name to open the detail drawer.
3

Review Details

View Job information including:
  • Completion progress (succeeded/target)
  • Active and failed pod counts
  • Duration and age
  • Container specifications
  • Events

​
How to Create a Job

1

Click Create Job

Click the Create Job button in the page header.
2

Write YAML

Enter the Job manifest in YAML format. Key fields:
  • spec.completions - Number of successful completions required
  • spec.parallelism - Max concurrent pods
  • spec.backoffLimit - Max retries before failure
  • spec.template - Pod template specification
3

Select Namespace

Choose the target namespace for the Job.
4

Create

Click Create to apply the manifest.
For recurring tasks, use CronJobs instead. Jobs are for one-time executions.

​
How to Edit a Job

1

Open Actions Menu

Click the actions menu (three dots) on the Job row.
2

Click View YAML

Select View YAML to open the editor.
3

Modify Spec

Edit the Job specification. Note that most Job fields are immutable after creation.
4

Save

Click Update to apply changes.
Most Job spec fields are immutable after creation. To change completions, parallelism, or the pod template, delete and recreate the Job.

​
How to Delete a Job

1

Open Actions Menu

Click the actions menu on the Job row.
2

Click Delete

Select Delete from the menu.
3

Confirm

Confirm the deletion.
Deleting a Job uses the Background propagation policy by default. Pods created by the Job are deleted asynchronously.

​
Job Completion Modes

ModeDescription
Non-indexedJob completes when completions pods succeed (default)
IndexedEach pod gets an index (0 to completions-1), useful for parallel processing with distinct work items

​
Parallelism and Completions

SettingBehavior
completions: 1, parallelism: 1Single pod, runs once (default)
completions: N, parallelism: 1Sequential execution of N pods
completions: N, parallelism: MUp to M pods run in parallel until N complete
completions: unset, parallelism: NWork queue pattern - pods run until one succeeds

​
Troubleshooting

  • Check if namespace has resource quotas blocking pod creation
  • Verify the container image exists and is accessible
  • Check for missing ConfigMaps, Secrets, or PVCs
  • Review Job events for scheduling errors
  • Check pod logs for application errors
  • Verify command and arguments are correct
  • Check if required environment variables are set
  • Review resource limits - pods may be OOMKilled
  • Increase backoffLimit if retries are expected
  • Set spec.activeDeadlineSeconds to limit total runtime
  • Check if pods are stuck waiting for resources
  • Review pod logs for slow operations
  • Consider increasing parallelism
  • Set ttlSecondsAfterFinished to auto-delete completed Jobs
  • Jobs created by CronJobs are cleaned up by history limits
  • Manually delete old Jobs if needed
  • Verify Job status and events
  • Check for selector mismatch between Job and pod template
  • Review namespace resource quotas
  • Check ServiceAccount permissions if using custom accounts
  • This shouldn’t happen normally
  • Check if ttlSecondsAfterFinished is set
  • Manually delete orphaned pods if needed

​
FAQ

Deployments keep pods running indefinitely and replace them if they fail. Jobs run pods to completion and consider success when the task finishes. Use Jobs for batch tasks, Deployments for services.
Use a CronJob, which creates Jobs on a time-based schedule. The CronJob controller automatically creates Jobs at specified intervals.
The Job controller creates a new pod up to backoffLimit times. Each retry uses exponential backoff (10s, 20s, 40s…, capped at 6 minutes). After exceeding the limit, the Job is marked Failed.
No. Jobs cannot be restarted. Delete the failed Job and create a new one with the same specification.
Set spec.activeDeadlineSeconds to specify the maximum runtime in seconds. The Job will be terminated if it exceeds this duration, regardless of completion status.
This field automatically deletes completed Jobs after the specified number of seconds. For example, ttlSecondsAfterFinished: 3600 deletes the Job one hour after completion.
Use a Job with parallelism set but completions unset. Each pod processes items from a shared queue until the queue is empty, then exits successfully.
The default backoffLimit is 6, meaning Kubernetes will retry failed pods up to 6 times before marking the Job as failed.
Most fields are immutable. You can update some metadata (labels, annotations) but not the pod template, completions, or parallelism. For changes, delete and recreate the Job.