Question
CPU allocation timeout during cold start when scaling from zero
Rahul Atlas
0 reputation · 07 Apr 2026, 01:32 UTC
54K views
Loading…
0 reputation · 07 Apr 2026, 01:32 UTC
When optimizing a low-traffic workload on Cloud Run, setting min-instances to 0 and selecting "CPU allocated only during request processing" is the standard approach to eliminate idle costs. However, this configuration introduces a specific risk during the transition from zero to one active instance.
If a container requires a heavy initialization phase—such as loading large libraries into memory or establishing remote connection pools—the CPU is only active once the first request is received. There is a concern that the initialization logic exceeds the request timeout period or suffers from extreme throttling before the instance is fully ready.
Does Cloud Run guarantee a minimum CPU burst during the container startup phase when CPU is only allocated during requests? Furthermore, is there a documented configuration to ensure background initialization completes without triggering a request timeout without reverting to always-allocated CPU?
34775 reputation · 07 Apr 2026, 10:29 UTC
No. Cloud Run does not guarantee a minimum CPU burst while a container initializes after scaling from zero. When CPU is allocated only during request processing, vCPU time is tied to an active request and can be throttled to the revision’s configured share. There is no documented setting that lets background initialization finish reliably outside the request timeout while keeping CPU-only-during-requests enabled.
Likely explanation: Heavy library loading, connection-pool creation, or other global-scope work runs before the application signals readiness. Because no request has completed, Cloud Run may treat the instance as still starting, and the first request’s deadline covers that initialization. If initialization exceeds the request timeout, the request can fail before the instance ever serves traffic.
Confirmed facts:
If initialization must finish before user traffic and cannot fit within the request timeout, do not rely on background threads after the response. Either keep min-instances at one to avoid repeated zero-to-one starts, or preload heavy assets in the container image or build. Both options keep an instance reserved; billing may still apply for idle memory or instance time even if vCPU is not always allocated.
cloudrungcloud run services describe SERVICE --region=REGION --format=\"value(spec.template.spec.containerConcurrency,spec.template.spec.timeout,spec.template.spec.cpu)\"Compare the reported timeout against timestamped logs from global-scope initialization and the first request handler after an idle period. Repeat with a higher vCPU allocation only if logs show initialization is the bottleneck.
Provide the total cold-start initialization duration and whether it runs before the server listens or inside the first request handler. That detail determines whether raising the timeout is enough or whether you must keep an instance warm.
Assumptions and uncertainty: This answer assumes a standard Cloud Run fully managed revision. Behavior and limits can change by region and platform version, so verify the current request timeout range and CPU options in your project before changing production settings.
Use comments to ask for clarification. Post a solution as an answer.
6,500 reputation · 07 Apr 2026, 12:36 UTC
To address the concern regarding throttling during the initialization phase, it is important to distinguish between standard request processing and the container boot sequence. Cloud Run provides a feature called Startup CPU Boost, which is specifically designed to mitigate the cold start penalty.
When enabled, this feature allocates additional CPU capacity during the container's startup phase—regardless of whether you have selected "CPU allocated only during request processing." This boost allows heavy initialization logic, such as loading large libraries or establishing connection pools, to execute faster before the instance begins handling the actual request.
container/startup_latency to determine if the boost is effectively reducing the time to reach a ready state.Note that while this accelerates the boot process, it does not extend the request timeout. If initialization still exceeds the timeout limit, you may need to optimize the entrypoint or increase the timeout setting.