Cloud Run Costs: Min Instances and Billing Mode

Two billing modes, one hidden floor

Cloud Run services are billed under one of two billing settings. With request-based billing, the default, instances are charged only when they process requests, start and shut down. With instance-based billing, you pay for the entire lifecycle of each instance, even when no requests arrive, in exchange for CPU that stays available for background work.

The second driver is minimum instances. Google’s min-instances page is explicit: Cloud Run keeps at least that many instances running even if they are not processing requests, and those instances incur billing costs. The default is 0. Under request-based billing idle minimum instances are charged at a lower idle rate; under instance-based billing they are charged the full rate. The pricing page lists idle min-instance time as its own line.

So a Cloud Run service is never stopped in the VM sense. It serves traffic or it scales to zero, and the money you can recover is the always-warm floor someone configured, plus the billing mode chosen for it.

Which knob fits which service

• A service with bursty traffic and no background work: request-based billing, min instances 0.
• A latency-sensitive production API: keep min instances, but size them from real traffic rather than a guess.
• A dev or test service with min instances above 0: that warm floor is paying for cold-start protection nobody needs overnight.

What ZopNight checks

Three rules in the GCP catalog target Cloud Run services directly:

• GCP Cloud Run Service With Idle Min Instances fires when request count stays near zero over a 30-day window while min instances are set. The lever is scaling min instances to 0, which is reversible, and the saving is priced from the warm instances’ vCPU and memory rates.
• Cloud Run Dev/Test Service Has Min Instances > 0 uses the same pricing on non-production services.
• Cloud Run Service Low Concurrency looks at whether each instance is handling enough simultaneous requests to justify its size.

Each finding carries its measured evidence and a monthly cost estimate, and appears next to the rest of your GCP recommendations at GCP recommendations. Cloud Run services can also go on a ZopNight schedule: the stop sets minimum instances to 0. The start does not put the previous floor back, so if the service needs a warm floor in working hours, set it again yourself; for a floor nobody needs, the recommendation route above is the cleaner fix.

Resource details live on the Cloud Run fact sheet, and the Cloud Run scheduling notes explain what an off-hours min-instance change does and does not save. Functions deployed as Cloud Run services are covered on the Cloud Functions page.