GCP Cloud Run min instances cost: what keeping instances warm costs

Quick answer

Cloud Run scales to zero by default, so you pay nothing when there is no traffic, but that means the first request after idle pays a cold start. Setting a minimum number of instances keeps that many warm, and each warm idle instance bills for its allocated CPU and memory at a reduced idle rate, roughly 0.0000025 dollars per vCPU-second and 0.0000025 dollars per GiB-second, continuously. One always-on instance with 1 vCPU and 512 MiB costs a few dollars a month at the idle rate. The tradeoff is min instances trade a continuous idle charge for the elimination of cold starts, so they are worth it only for latency-sensitive services with steady enough traffic to justify the always-on cost.

Cloud Run's headline feature is scaling to zero: when no requests arrive, no instances run and you pay nothing for compute. The cost of that elegance is the cold start, the extra latency when a request arrives and an instance must spin up. Minimum instances buy that latency away by keeping instances warm, but warm instances bill continuously, so the feature is a deliberate cost tradeoff, not a free improvement.

How Cloud Run billing works

State	Billing
Handling a request	Full CPU and memory rate for the request duration
Idle warm (min instance)	Reduced idle rate for allocated CPU and memory
Scaled to zero	No compute charge
Requests	About 0.40 dollars per million

In the default request-based billing model, Cloud Run charges for CPU and memory only while an instance is handling requests, plus a per-request fee of about 0.40 dollars per million and a small allocation. When you set minimum instances, those instances stay alive between requests, and Cloud Run bills their allocated CPU and memory at a reduced idle rate, roughly 0.0000025 dollars per vCPU-second and 0.0000025 dollars per GiB-second, for every second they are kept warm.

What a warm instance costs

Work an example. One always-on instance with 1 vCPU and 512 MiB at the idle rate costs about 0.0000025 for the vCPU plus 0.00000125 for the memory per second, near 0.00000375 dollars per second, which is roughly 9.7 dollars per month per instance kept warm around the clock. Two minimum instances double that. The number is small per instance but scales with how many you keep warm and how much CPU and memory each is allocated, so a service pinned to several large warm instances adds up.

When min instances are worth it

Minimum instances make sense for latency-sensitive services where a cold start would hurt the user experience, an interactive API, a checkout path, a service behind a strict latency target. For background workers, batch endpoints, and low-traffic internal tools, scaling to zero and accepting the occasional cold start is cheaper and perfectly acceptable. The decision mirrors the general cold start mitigation tradeoff: pay continuously to remove latency, or pay nothing and tolerate it.

Tuning the setting

Set the minimum to the smallest number that keeps your latency acceptable, often one or two, rather than provisioning for peak. Keep the per-instance CPU and memory allocation right-sized, since the idle charge scales with both. For services with predictable daily patterns, consider whether the traffic is steady enough that min instances pay off, or spiky enough that scaling to zero off-hours is cheaper. This connects to the broader Cloud Run versus GKE cost picture. Price your Cloud Run service with and without min instances against the resource catalog so the always-on idle cost is a known number before you enable it.

FAQ

What do Cloud Run minimum instances cost?

Each warm idle instance kept alive by the minimum-instances setting bills for its allocated CPU and memory at a reduced idle rate, roughly 0.0000025 dollars per vCPU-second and 0.0000025 dollars per GiB-second, continuously. One always-on instance with 1 vCPU and 512 MiB costs about 9.7 dollars per month at the idle rate, and the cost scales with the number of warm instances and their allocation.

Why would I set minimum instances on Cloud Run?

To eliminate cold starts. Cloud Run scales to zero by default, so the first request after idle must spin up an instance, adding latency. Minimum instances keep that many warm so requests are served immediately. This is worth the continuous idle charge for latency-sensitive services like interactive APIs or checkout paths, but not for background workers or low-traffic internal tools.

How much does one always-on Cloud Run instance cost per month?

At the idle rate, an instance with 1 vCPU and 512 MiB costs about 0.00000375 dollars per second kept warm, which is roughly 9.7 dollars per month if kept warm around the clock. Larger CPU and memory allocations or more minimum instances multiply that figure, so a service pinned to several large warm instances can add up meaningfully.

Should every Cloud Run service use minimum instances?

No. Minimum instances suit latency-sensitive services where a cold start would hurt the user experience. For background workers, batch endpoints, and low-traffic internal tools, scaling to zero and accepting the occasional cold start is cheaper and perfectly acceptable. Set the minimum to the smallest number that keeps latency acceptable, often one or two, rather than provisioning for peak.

How does C3X help with Cloud Run cost?

C3X prices your Cloud Run configuration from Terraform before you deploy, including the continuous idle cost of minimum instances and the per-instance CPU and memory allocation. That lets you see what keeping instances warm will cost each month and decide at design time whether the latency benefit justifies the always-on charge, rather than discovering the idle cost on the bill.

What to do next

See the idle cost of warm instances before you enable them. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.