Does enabling unauthenticated invocations on Cloud Run alter the 60‑minute request timeout limit?

Question

Goal: Verify whether the 60‑minute request timeout enforced by Cloud Run applies equally to invocations that are allowed unauthenticated access, so that integration tests can rely on the same safety net without using production credentials.
Constraints: Cloud Run’s timeout is a hard upper bound that cannot be raised; it covers the entire request lifecycle, including container startup latency and response streaming. Enabling unauthenticated access is done by binding the run.invoker role to allUsers, which is documented but does not mention any timeout variation.
Uncertainty: The public documentation does not explicitly state whether the timeout measurement or error handling differs for unauthenticated requests, leaving it unclear if tests should expect identical 504 Gateway Timeout behavior.

Is the 60‑minute timeout applied identically to unauthenticated invocations?
Does the timeout count container startup latency the same way for unauthenticated calls?
Does Cloud Run return the same HTTP 504 error when an unauthenticated request exceeds the limit?

Tasadduq Burney · Answer

Answer
Yes. Enabling unauthenticated invocations on Cloud Run does not change the 60‑minute request timeout.
Confirmed facts

The 60‑minute limit is a hard upper bound enforced by Cloud Run for every request, regardless of authentication status.
Binding the run.invoker role to allUsers (unauthenticated access) only affects IAM permission checks; it does not alter timeout measurement or error handling.
Container startup latency (cold start) is included in the timeout for both authenticated and unauthenticated calls.
When a request exceeds the limit, Cloud Run returns an HTTP 504 Gateway Timeout with the same headers and body for both types of invocations.

Steps to verify

Deploy a Cloud Run service (e.g., gcloud run deploy test-service --image=gcr.io/cloudrun/hello --allow-unauthenticated).
Ensure the service’s handler sleeps longer than 60 minutes (e.g., sleep 4000 in a simple script) so the request will exceed the timeout.
Send an HTTP request with a client that does not impose a shorter timeout (e.g., curl -v --max-time 0 https://SERVICE_URL or a custom script with a long timeout).
Observe the response: HTTP 504 Gateway Timeout, identical to the response when the same request is made against a service that requires authentication.

Does enabling unauthenticated invocations on Cloud Run alter the 60‑minute request timeout limit?

1 answer

Answer

Confirmed facts

Steps to verify

Your perspective belongs here.

0 question comments