Build Cloud Run Jobs with task count, parallelism, retries, env/secrets, and scheduling in gcloud and Terraform.
Last verified: May 2026
Lowercase, hyphens, 1-49 characters, starting with a letter
No environment variables configured.
No secrets configured.
Cloud Scheduler cron expression
Output will appear here...Cloud Run Jobs run tasks to completion and then exit, ideal for batch processing, data pipelines, and scheduled work. Cloud Run Services handle HTTP requests and run continuously. Jobs don't need to listen on a port and are billed only while tasks execute.
Each job execution creates task count independent tasks. The parallelism setting controls how many tasks run concurrently. Each task gets a CLOUD_RUN_TASK_INDEX (0 to N-1) and CLOUD_RUN_TASK_COUNT environment variable for work distribution.
Failed tasks are retried up to max retries times. A task is considered failed if the container exits with a non-zero code or exceeds the timeout. Use exit code 0 for success.
Use Cloud Scheduler to trigger job executions on a cron schedule. The scheduler invokes the Cloud Run Admin API to start a job execution. Requires OAuth authentication with a service account that has the roles/run.invoker role.
Cloud Run Jobs: serverless, fast startup, up to 24h timeout, simpler container model, good for moderate batch work. Cloud Batch: supports GPUs, longer runtimes, VM-level configuration, MPI workloads, better for HPC and large-scale batch computing.
Your data team runs a nightly ETL that processes 10,000 customer files sequentially in a 6-hour Compute Engine job — a single failure 5 hours in restarts the whole thing. You migrate to Cloud Run Jobs with taskCount=100, parallelism=20: each task processes 100 files using CLOUD_RUN_TASK_INDEX to shard. Total runtime drops to 30 minutes. A failed task auto-retries up to 3 times without re-running successful tasks. CE VM cost: ~$45/run. Cloud Run Jobs cost: ~$8/run. Faster, cheaper, more reliable.
The Cloud Run Jobs Builder helps you configure Cloud Run Jobs with task count, parallelism, retry policies, environment variables, secret references, and scheduling. Unlike Cloud Run services that respond to HTTP requests, jobs run to completion and are ideal for batch processing, data migrations, and scheduled tasks. The tool generates gcloud CLI commands and Terraform configurations.
The builder constructs a Cloud Run Jobs Job specification with template.spec containing parallelism, taskCount, retries, taskTimeout, and the container spec (image, env vars, secrets, CPU, memory). It outputs gcloud run jobs create commands, Terraform google_cloud_run_v2_job resources, and YAML for kubectl apply via Cloud Run for Anthos.
Cloud Run Jobs is what Cloud Functions 1st gen tried to be for batch — proper task arrays, parallelism control, automatic retries, and a 24-hour max runtime (vs Functions' 9-minute cap). For any batch job longer than 5 minutes, Cloud Run Jobs is dramatically better than chaining Functions.
The CLOUD_RUN_TASK_INDEX env var (0 to taskCount-1) is the killer feature for parallel batch processing. Use it to shard work: each task processes index/totalTasks of the input. No coordinator needed, jobs scale linearly to taskCount.
Cloud Run Jobs charge for the FULL allocated CPU/memory during execution, not just active CPU like Cloud Run services with CPU-during-request. A job with 4 vCPU allocated that's mostly waiting on I/O still bills for 4 vCPU. Right-size carefully — over-allocation wastes money on Jobs more than on Services.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.