Cloud Run request timeout is capped at 60 minutes per request

The problem is a request that dies after a few minutes with no code error

If a Cloud Run service handles a long-running HTTP request, the platform will terminate it when the per-request timeout is reached. The useful takeaway is that Cloud Run enforces a hard maximum of 60 minutes per request, the timeout is set on the service, not in the container, and exceeding it returns a 504 from the platform before your code can finish.

Many teams confuse this with the idle instance lifetime. The per-request timeout controls how long a single invocation may run. A separate platform behavior controls how long an idle instance is kept warm, which is not configurable via the timeout field.

How the timeout is configured and enforced

Cloud Run reads the timeout from the service configuration. It applies to each incoming HTTP request routed to a container revision. When the limit is reached, the Cloud Run proxy aborts the connection and returns an error to the caller. The container may be stopped and the instance can be scaled down.

Set the timeout at deploy time

Run the command from a workstation with the Cloud SDK installed and authenticated. The deployer needs IAM permission to update Cloud Run services, typically roles/run.admin or roles/run.developer in the target project.

gcloud run deploy my-service \
  --image=gcr.io/PROJECT/IMAGE \
  --region=REGION \
  --timeout=30m

Placeholders: PROJECT is your GCP project id, IMAGE is a container image reference, REGION is a Cloud Run supported region, and the timeout value uses minutes or seconds, e.g., 30m or 1800s. The maximum accepted value is 60 minutes. Values above 60 minutes are rejected by the API.

The same field appears in the service configuration as timeout. A YAML snippet for review looks like:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: my-service
spec:
  template:
    spec:
      timeoutSeconds: 1800

timeoutSeconds is in seconds. 1800 equals 30 minutes. This is for planning only; do not assume the example has been deployed.

Verify the current setting

Describe the service and inspect the timeout field. Run this from any machine with gcloud credentials.

gcloud run services describe my-service --region=REGION --format=json

Check the timeout value in the output under the revision template. A practical check is to compare the configured timeout with the expected maximum workload duration and ensure a margin for cold start and processing overhead.

Risks of raising the timeout: longer-running requests keep an instance busy and billed for the full duration. Increasing the timeout does not increase concurrency; each instance still handles one request at a time unless the container is designed for concurrency.

Limits and common mistakes

Maximum limit. Cloud Run does not allow a per-request timeout above 60 minutes regardless of instance type or memory. Requests that would need more time must be redesigned.

No automatic retry. When the platform aborts at the timeout, the client receives an error such as HTTP 504. Cloud Run does not retry the request for you.

Background work anti-pattern. Using a long timeout to run background jobs is fragile. If the work must continue after the client disconnects, use Cloud Tasks or Pub/Sub to decouple the request from processing.

Idle instance confusion. The 15 minute idle instance lifetime is a separate platform behavior. Changing the request timeout does not change how long an unused instance stays warm.

Cost awareness. Billing is per request and per instance time used. A high timeout combined with low traffic can increase cost because instances may remain allocated for the full request duration.

Verification note. The 60 minute maximum and the behavior of returning an error when the limit is exceeded should be verified against current Cloud Run documentation before relying on it in production, as platform limits can change.