Cloud Run pricing is vCPU-seconds and GiB-seconds of memory per instance, rounded up to 100 milliseconds, under one of two billing models: request-based, where an instance pays its active rate only while it handles requests and an idle rate while a minimum instance waits, plus a price per million requests; or instance-based, where the instance pays a lower rate for every second it exists, requests included. Jobs and worker pools pay their own per-second rates, a free tier per month covers small services, and the network, the ephemeral disk and GPUs come on top. Cloud Run functions are Cloud Run services and pay the same. On the bill, the minimum instances dominate on services that are kept warm, the CPU seconds on services that are busy, and the egress on services that answer large responses.

Pricing dimensions

Google sells Cloud Run by the second of an instance's existence or activity, never by the container; every rate has its own SKU per region, and Frankfurt sits in the dearer of the two price tiers.

DimensionUnitWhat drives itOptional
Request-based billingvCPU-second and GiB-second while an instance handles requests, at the active rate; a lower idle rate for CPU and memory while a minimum instance waits; USD per million requestsServices whose CPU is allocated only during requestsYes, the default for services
Instance-based billingvCPU-second and GiB-second for every second an instance exists, at a lower rate than active, requests freeServices with CPU always allocated, background work, WebSocketsYes
Minimum instancesThe idle rate per vCPU-second and GiB-second for instances kept warm while no request runs; instances the autoscaler keeps beyond the minimum are not charged idleServices that must answer without a cold startYes
JobsvCPU-second and GiB-second of the job's tasks at their own rateBatch and scheduled workYes
Worker poolsvCPU-second and GiB-second of pool instances at their own rate, no requestsQueue consumers and long-running workersYes
Free tier180,000 vCPU-seconds, 360,000 GiB-seconds and 2 million requests a month at request-based rates, 240,000 vCPU-seconds and 450,000 GiB-seconds at instance-based and job rates, priced at the us-central1 rateEvery billing account, once a month across its servicesYes
GPUsGPU-second per attached accelerator while the instance exists, with CPU always allocatedInference services with an L4Yes
Ephemeral diskGiB-hour of in-memory or disk-backed ephemeral storage beyond the memoryServices that write large temporary filesYes
NetworkOutbound internet traffic at network rates, with 1 GiB free within North America a month; inbound free; to other Google Cloud services in the region freeResponses and calls out of the regionYes (network pricing)
Purchase optionCompute flexible committed use discounts over one or three years cover Cloud Run CPU and memory at 17 and 46 percent off in Frankfurt on the read dateSteady loadYes (Google Cloud committed use discounts)

The billing model is the decision: request-based pays about 55 percent more per vCPU-second than instance-based, but only for the seconds a request is in flight, so a service that answers a request every few seconds pays a fraction of its instance's life, while a service that is busy most of the time pays more than it would with instance-based billing, where every second counts at the lower rate. Minimum instances change the arithmetic: a warm instance pays the idle rate every second it waits, about a tenth of the active rate for CPU and the full rate for memory, so a minimum of one instance with 1 vCPU and 512 MiB costs a few dollars a month and a minimum of ten with 4 vCPUs and 16 GiB costs hundreds. Concurrency is the hidden lever: an instance that handles 80 requests at once pays its seconds once, an instance limited to one request pays them per request. Cloud Run functions, since the merge of the second generation into Cloud Run, are services and pay by the same models, with the concurrency set to one by default on functions written for one request at a time. The mechanics across all three providers are in serverless functions; what the choice between a container and a VM costs, in architecture choices and cost.

How it appears in your billing data

In the billing export the rows carry service.description Cloud Run and a sku.description per resource, model and region: Cloud Run CPU Allocation Time (europe-west3) and Cloud Run Memory Allocation Time (europe-west3) for request-based active time, Cloud Run Idle CPU Allocation Time and Cloud Run Idle Memory Allocation Time for minimum instances, Cloud Run Requests per million, Cloud Run Services CPU Always Allocated and Memory Always Allocated for instance-based billing, Cloud Run Jobs CPU and Cloud Run Jobs Memory for jobs, Cloud Run Worker Pools CPU for worker pools, Cloud Run GPU L4 per second; usage.unit is second for vCPU, gibibyte-second for memory and count for requests. resource.name in the export with resource-level detail names the service, job or worker pool, and the service's labels in labels are the attribution per team; a function deployed through the functions API carries the labels the deployment set. The free tier appears as credits.type FREE_TIER beside the rows it offsets, at the us-central1 rate, so in Frankfurt it covers fewer seconds than its name says.

A flexible commitment that covers Cloud Run appears as COMMITTED_USAGE_DISCOUNT beside the CPU and memory rows; there is no sustained use discount. The export's structure is described in the Google Cloud billing export; in the FOCUS export, ServiceName carries Cloud Run, ServiceCategory Compute, SkuId the SKU and ChargeCategory Usage (FOCUS columns). What the export does not show is why the seconds were billed: the service's metrics, billable instance time by state, container instance count and request count, separate active from idle and busy from waiting.

request-basedinstance-basedA Cloud Run serviceBilling model?CPU and memory allocation timewhile a request runs, plusrequests per millionCPU and memory alwaysallocated, for the instance'swhole lifetimeIdle CPU and memory allocationtime for every minimum instance,all monthA flexible commitment: acommitted use discount creditbeside the CPU and memory rows
The billing model decides which SKUs a service produces, active or always-allocated time with idle time for warm instances, and a flexible commitment credits them

Levers

Configuration: the first lever is the billing model per service, request-based for services that wait between requests and instance-based for services that work all the time or run background threads; the second is concurrency, because an instance that serves many requests at once pays its seconds once, and a concurrency of one on a service that could take 50 multiplies the instances; the third is the minimum instance count, because every warm instance pays idle seconds all month and a minimum of zero costs a cold start instead. The instance size is the fourth: CPU and memory pay per second in proportion, and a service with 2 vCPUs that uses one pays double (rightsizing).

waits betweenrequestsworks all the time or runsbackground threadsyesnoHow does theservice work?Request-based: paysonly while servingInstance-based: pays theinstance's whole lifetimeConcurrency: an instance servingmany requests at once pays itsseconds once; concurrency onemultiplies the instancesDoes the coldstart matter?One warm minimum instance:idle seconds all monthMinimum zero
The billing model by how the service works, concurrency so one instance's seconds serve many requests, and a minimum instance only where the cold start matters

Purchase option: the flexible committed use discount covers Cloud Run, Compute Engine and GKE in one spend commitment, which makes it the way to discount a steady Cloud Run baseline without committing to one service (commitment strategy).

Architecture: jobs for batch work instead of a service that polls, worker pools for queue consumers instead of a service with a minimum instance, and a VM or GKE for services that run at full load around the clock, where instance-based Cloud Run costs about twice an E2 vCPU on Compute Engine (Compute Engine pricing, Google Kubernetes Engine pricing). Responses behind a CDN where they repeat, because egress pays per GiB.

Where it goes wrong

  • Ten warm instances for one request a minute. Minimum instances pay idle seconds all month. Idle CPU Allocation Time beside a small request count is the clue; a minimum of one, or zero with a cold start the users tolerate.
  • Concurrency of one on a web service. Every request gets its own instance and its own seconds. The concurrency setting multiplies or divides the bill without changing the code.
  • Request-based billing on a busy service. A service in flight 90 percent of the time pays the active rate for most of its life; instance-based billing is cheaper from about two thirds utilisation.
  • The background thread is not billed, until it is. Under request-based billing the CPU is throttled between requests; work that must run between requests needs instance-based billing, and then every second counts.
  • The function polls. A function invoked every second by a scheduler pays a request and seconds each time. A job or a worker pool does the same work at the lower rate.
  • The response is the egress. A service that serves images pays per GiB to the internet, more than its CPU. A CDN in front caches the repeats.
  • The free tier counted at the wrong rate. The free seconds are valued at the us-central1 price and offset fewer seconds in Frankfurt; the credit row shows the difference.

Example

List prices in USD for Frankfurt (europe-west3), read on 2026-10-21 from the Cloud Run pricing page: request-based billing costs USD 0.0000336 per vCPU-second and USD 0.0000035 per GiB-second while an instance handles requests, USD 0.0000035 per vCPU-second and per GiB-second while a minimum instance idles, and USD 0.40 per million requests; instance-based billing USD 0.0000216 per vCPU-second and USD 0.0000024 per GiB-second for every second an instance exists; jobs USD 0.00001512 per vCPU-second and USD 0.00000168 per GiB-second; worker pools USD 0.000013493 and USD 0.000001482; with the flexible commitment over three years USD 0.000011664 per vCPU-second instance-based; ephemeral disk USD 0.000131507 per GiB-hour.

A service with 1 vCPU and 512 MiB that handles 10 million requests a month of 200 ms each at a concurrency of 1 pays 2,000,000 vCPU-seconds and 1,000,000 GiB-seconds under request-based billing, 67.20 plus 3.50 plus 4.00 = USD 74.70 before the free tier; the same requests at a concurrency of 20 pay a twentieth of the seconds, USD 7.54, because the instances overlap. A minimum of one such instance adds 2,628,000 idle seconds, 9.20 plus 4.60 = USD 13.80 a month; a minimum of ten instances with 4 vCPUs and 16 GiB adds USD 1,840 of idle time. A service busy around the clock with 2 vCPUs and 4 GiB pays USD 213.72 a month under instance-based billing and USD 213.72 × 1.56 = USD 332.90 under request-based billing if it were in flight all the time; the same 2 vCPUs on an e2-standard-2 cost USD 63.02. A nightly job that runs 30 minutes on 4 vCPUs and 8 GiB costs 30 × (7,200 × 0.00001512 + 14,400 × 0.00000168) = USD 3.99 a month. The figures show that concurrency and minimum instances, not the request price, decide the bill, and that Cloud Run is cheap for bursty services and dear for services that never rest.

Sources

Read on 2026-10-21. Prices: Cloud Run pricing. Service: billing settings for Cloud Run services, minimum instances, maximum concurrent requests per instance. Billing data: structure of the standard Cloud Billing data export.