Jobs

A job runs containerized work to completion. Choose a job when a workload needs to start, do a bounded amount of work, report success or failure, and stop.

Container apps are for continuously available services. Jobs are for finite work such as scheduled maintenance, batch processing, manual operations, or event-triggered tasks.

caution

Jobs do not have revisions. Revision-based rollout, labels, and traffic splitting are app concepts. A job definition describes the default configuration for future executions, and each execution is one run of that job.

At a glance

Job concept	What it means
Workload type	Run-to-completion work with a clear start and end.
Runtime unit	Job executions made up of one or more replicas.
Start options	Manual start, cron schedule, or event scale rule.
Updates	Job definition changes affect future executions.
Good for	Batch, maintenance, one-off, scheduled, or event-triggered tasks.

What is a job?

A Container Apps job is a resource for run-to-completion work. The job definition stores the container template and default execution settings. When the job starts, Azure Container Apps creates a job execution. The execution runs one or more replicas until the configured completion behavior is reached or the execution fails.

Jobs and apps share the Container Apps environment, including networking and logging. Their lifecycle sets them apart. An app remains available as a service, while a job execution ends.

For setup details and command examples, see Jobs in Azure Container Apps.

Jobs vs. apps

Concept	App	Job
Workload type	Long-running service	Run-to-completion task
Runtime unit	Revision replicas	Job execution replicas
Start model	Service demand or configured scale	Manual start, schedule, or event
Updates	Revision-scoped template changes	Job definition changes for future executions
Good for	Web apps, APIs, microservices, continuous workers	Batch, maintenance, one-off, scheduled, or event-triggered tasks

Use an app when something should keep accepting requests or continuously process work. Use a job when the work has a clear beginning and end.

The job mental model

Part	Role in the job model
Job definition	Reusable configuration for future executions.
Job execution	One run of the job.
Job replica	A running instance of the job template inside an execution. It can include one or more containers.

Job definition

The job definition stores reusable configuration. It includes the container template, trigger type, execution behavior, scale settings for event jobs, secrets, registries, identity, and related settings.

note

Changing the definition changes how later executions are created. It does not create an app-style revision.

Job execution

A job execution is one run of the job. Manual jobs create executions when you start them. Scheduled jobs create executions from a cron schedule. Event jobs create executions when their scale rules detect work.

A job execution runs until it completes or fails. It can use settings such as replica completion count, parallelism, replica retry limit, and replica timeout.

Execution setting	What it controls
Replica completion count	Defines how many successful replica completions are required.
Parallelism	Controls how many replicas can run at the same time.
Replica retry limit	Sets the maximum number of times a replica can be retried.
Replica timeout	Sets the maximum number of seconds a replica can run before it's stopped.

Job replica

A job replica is a running instance of the job template inside an execution. It can include one or more containers. A single execution can run one replica or multiple replicas, depending on the job's replica completion count and parallelism settings.

Use replicas when the work can be split across concurrent workers in the same execution.

How jobs start

A job uses one of three trigger types.

Trigger type	Use it when...	How executions are created
Manual	Another person, tool, or automation system should decide when the work starts.	You start the job.
Schedule	The work should start on a recurring cron schedule.	The cron expression creates executions.
Event	External work should create executions.	Scale settings and scale rules watch for work and start executions.

Manual

Use a manual job when another person, tool, or automation system should decide when the work starts. A manual job can represent a maintenance task, a backfill, or a one-off processing run.

Manual jobs use replica completion count and parallelism settings to determine how many replicas must finish and how many can run at the same time.

Schedule

Use a scheduled job when the work should start on a recurring cron schedule. Scheduled jobs also use replica completion count and parallelism settings, with a cron expression added to define when executions are created.

tip

For cron syntax and examples, see Jobs in Azure Container Apps.

Event

Use an event job when external work should create executions. Event jobs use scale settings and scale rules to watch for work and start executions.

For event-driven setup details and KEDA scale-rule examples, see Tutorial: Deploy an event-driven job with Azure Container Apps.

When to choose a job

Choose a job when:

• The workload has a clear end condition.
• You want each run to be tracked as an execution, with history retained for a limited number of recent executions.
• Work should start manually, on a schedule, or in response to events.
• Replicas can complete independently or in parallel.
• You do not need HTTP traffic management, revision labels, or traffic splitting.

info

Choose a container app instead when the workload must be available continuously or needs app revision behavior. For the app model, see Container apps.

Related content

• Jobs in Azure Container Apps: Learn job concepts, permissions, and create examples.
• Tutorial: Deploy an event-driven job: Configure event-triggered work.
• Containers in Azure Container Apps: Learn the container template settings jobs share with apps.
• Container apps: Compare jobs with continuously available services.
• Dynamic Sessions and Sandboxes: Compare isolated execution models when the work should run away from your main app process.