REW

How Long Is Google Cloud Run Time Limit?

Published Aug 29, 2025 3 min read
On this page

The time limit for a Cloud Run service request is 60 minutes, which can be configured during deployment.

Cloud Run time limits explained in detail

Google Cloud Run offers two distinct compute models, each with its own time limits that are crucial for developers to understand:

  • Cloud Run Services: For handling web requests and event-driven workloads.
  • Cloud Run Jobs: For non-HTTP, batch, or background tasks.

Time limits for Cloud Run services

Cloud Run Services are designed for synchronous, request-response applications, such as web APIs. The time limit for these is tied to the lifecycle of a single request.

  • Maximum timeout: 60 minutes (3600 seconds).
  • Default timeout: 5 minutes (300 seconds).

This timeout is the maximum duration an instance has to process a request and send a response. If the instance fails to respond within this time, the request is terminated, and a 504 error is returned to the client.

Important considerations for service timeouts:

  • Client vs. service timeout: The effective timeout is determined by the most restrictive setting. If your client has a 30-second timeout but the Cloud Run service is set to 60 minutes, the client will time out first.
  • Background activities: If you want your service to perform work after sending a response, you must enable "CPU always allocated" via instance-based billing. Otherwise, the CPU is throttled immediately after the response, and any background work will be terminated when the instance is shut down.
  • Network interruptions: Google advises that longer timeouts are more susceptible to network issues. For requests over 15 minutes, implement retries and ensure your service is idempotent or can resume work if a connection is lost.

Time limits for Cloud Run jobs

Cloud Run Jobs are a more recent feature designed for asynchronous, run-to-completion workloads like data processing or scheduled tasks. The time limit for these is applied per-task rather than per-request.

  • Maximum task timeout: 168 hours (7 days).
  • Default task timeout: 10 minutes (600 seconds).

A job can consist of a single task or multiple parallel tasks. A task runs until it is completed or until it reaches its configured timeout.

Key differences and use cases for jobs:

  • Ideal for batch workloads: This model is suited for tasks that don't need to serve an HTTP request and may take an extended period to complete.
  • No explicit job timeout: The overall job execution completes when all of its tasks are finished, with no overall execution limit beyond the sum of its tasks.
  • Task retries: You can configure a job to automatically retry a failed task, up to a maximum of 10 retries.

How to configure timeouts

You can set timeout values using the Google Cloud Console, the gcloud command-line tool, or a YAML configuration file.

Example using gcloud:

  • For a service:sh

    gcloud run services update SERVICE --timeout=3600
    

    Use code with caution.

  • For a job:sh

    gcloud run jobs create JOB_NAME --task-timeout=605s
    

    Use code with caution.

Choosing the right Cloud Run model

Your choice between a Service and a Job depends on the nature of your workload.

Feature Cloud Run Service Cloud Run Job
Primary purpose Serve HTTP requests, APIs, websites. Run asynchronous, run-to-completion tasks.
Max duration 60 minutes per request. 168 hours (7 days) per task.
Trigger HTTP/S requests, Eventarc events. Manually, via gcloud, or by a scheduler.
Scaling Scales based on incoming requests or CPU utilization. Scales based on parallelism and available resources.
Background work Requires "CPU always allocated" setting and instance-based billing. The entire task is a dedicated background process.
Best for Quick-responding applications, microservices. Batch processing, ETL pipelines, scheduled tasks.
Enjoyed this article? Share it with a friend.