# Request-based or instance-based billing on Cloud Run: which one to pick

> A Cloud Run service bills only while it handles requests, or for every second an instance lives. What each charges for, what the CPU does between requests, where costs cross, and how to switch.

Published 2026-10-11 · Updated 2026-10-13 · [By Exodus team](https://exodus.elim.io/about) · Pricing, Basics
<https://exodus.elim.io/blog/request-based-or-instance-based-billing>

Request-based billing, the default, is the cheaper choice for most Cloud Run services: it charges only while requests are in flight and stays cheaper until an instance is busy about 65-70% of the time. Instance-based billing is about 30% cheaper per second but charges every second an instance lives; pick it when code needs a CPU between requests or traffic runs around the clock.

## In short

- Request-based billing: $0.000024 per vCPU-second and $0.0000025 per GiB-second while busy, plus $0.40 per million requests. Instance-based: $0.000018 and $0.000002 for every second, no request fee.
- One instance of 1 vCPU and 512 MiB costs $49.93 a month on instance-based billing; request-based costs the same at about 70% busy, or 65% with one minimum instance.
- An idle minimum instance of that size costs $9.86 a month on request-based billing, a fifth of the instance-based price.
- Our staged site was busy 45.0 seconds in 24 hours: $0.04 a month before the free tier, against $49.93 kept up on instance-based billing.
- Instance-based billing needs at least 512 MiB of memory, and a GPU service must use it.

Prices are Google's list prices for tier 1 regions (such as `europe-west1` in Belgium and `us-central1` in Iowa), read on October 11, 2026.

## What each setting charges for

Every Cloud Run service has this one setting, and it decides two things at once: what Google charges for, and whether your code has a CPU when no request is running. Older posts use the old names: request-based billing was "CPU only allocated during request processing", instance-based billing was "CPU always allocated". In `gcloud` the switch is still named after the CPU: `--cpu-throttling` for request-based, `--no-cpu-throttling` for instance-based.

Cloud Run runs your service as **instances**: copies of your container, each with the vCPU and memory you configured. Billing counts seconds of an instance's life, multiplies them by its size, and rounds every stretch up to the nearest 100 milliseconds. What differs is which seconds count.

With **request-based billing** an instance is billed while it starts, while it shuts down, and while at least one request is in flight. Google defines the billed stretch as starting with the first request and ending with the end of the last one, so two requests that overlap on one instance are billed once, not twice. Between requests the instance is idle and costs nothing, unless it is one of the minimum instances you asked Cloud Run to keep warm, which have their own lower idle rate. There is also a fee per request, $0.40 per million. Requests that IAM refuses before they reach your container are not billed.

With **instance-based billing** an instance is billed from the moment its container starts to the moment it is stopped, idle or busy, with a minimum of one minute. There is no fee per request.

![A timeline of one instance: three requests, two of them overlapping, then idle time and a shutdown. Under request-based billing only startup, the requests and the shutdown are billed; under instance-based billing the whole lifetime is billed](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-a3d23a9be67ed49712e0972444090d28bb48fe40b60b3d8b6b1839eb92b9e44d-680x330-svg/bytes "What is billed on one instance. The two overlapping requests count once under request-based billing; the idle stretch after them is free there and billed under instance-based billing.")

How long can an idle instance live? Cloud Run's container contract says an instance that is not processing requests is not kept idle for longer than 15 minutes, unless it is a minimum instance. It can also be shut down sooner; before it stops, Cloud Run sends `SIGTERM` and gives it 10 seconds, and those 10 seconds are billed under both settings. So with instance-based billing and no minimum instances, a quiet service still pays for up to 15 minutes after each burst of traffic.

## The prices, October 11, 2026

Tier 1 list prices, in US dollars, from Google's pricing page:

- **Request-based billing.** CPU $0.000024 per vCPU-second and memory $0.0000025 per GiB-second while an instance is active; $0.40 per million requests. A minimum instance that is idle costs $0.0000025 per vCPU-second and $0.0000025 per GiB-second.
- **Instance-based billing.** CPU $0.000018 per vCPU-second and memory $0.000002 per GiB-second, for the whole life of the instance. No request fee.

Put those against one instance of 1 vCPU and 512 MiB, a common size for a small web app. A busy second on request-based billing costs $0.00002525 for CPU and memory. If the requests take 200 ms and run one at a time, that second also carries five requests, $0.000002 more, so $0.00002725. A second on instance-based billing costs $0.000019, busy or idle. Instance-based is about 30% cheaper per second, and you pay it for every second.

Each billing account also gets a free allowance every month. It is listed in seconds, and the lists differ between the two settings, but at each setting's own prices both are worth $4.32 of CPU and $0.90 of memory. [The Cloud Run free tier explained](https://exodus.elim.io/blog/the-cloud-run-free-tier-explained) has the lists, who shares them and what uses them up. The prices in this article are before the free tier unless it says otherwise.

Regions in tier 2, such as London, Frankfurt or Singapore, cost more per second under both settings. The comparison below holds there too, because both prices move with the region; [choosing a Cloud Run region](https://exodus.elim.io/blog/choosing-a-cloud-run-region) has the numbers.

## What the CPU does between requests

The billing setting is also a CPU setting, and this is the part that breaks code. The `gcloud` help says it plainly: `--cpu-throttling` means "throttle the CPU when the container is not actively serving requests". On request-based billing an idle instance keeps its memory but gets almost no CPU. Nothing crashes. Work that was meant to happen between requests just does not progress until the next request arrives, and then it competes with that request.

Google's billing page lists what needs a CPU outside requests:

- Work started after the response is sent: an email sent "in the background", a webhook to a third party, a cache warm-up.
- Goroutines, Node.js promises that outlive the response, Java threads and Kotlin coroutines doing work of their own.
- Frameworks with built-in schedulers, such as an in-process cron or a job runner inside the web process.
- Monitoring agents such as OpenTelemetry exporters that batch and send data in the background.

On a PaaS where the process runs all the time, all of these work. Moved to Cloud Run on the default setting, they stall: the email goes out minutes later, the metrics arrive in bursts, the nightly job never fires because nobody sent a request at midnight. [Work after the response](https://exodus.elim.io/blog/work-after-the-response) shows how to find such code and where to move it.

There are two fixes. The first is to keep request-based billing and move the work into requests: hand it to [Cloud Tasks](https://exodus.elim.io/blog/background-workers-with-cloud-tasks), which calls your service back with an HTTP request, retries on failure and allows a task to run up to 30 minutes, or to Cloud Scheduler for timers. The second is to switch the service to instance-based billing so the CPU stays on. Google's own advice for the second case is to combine it with at least one minimum instance, because without one, Cloud Run still scales an idle service down to zero and the background work stops with it.

Even with instance-based billing an instance can stop at any time. Trap `SIGTERM` and finish or hand back the work in the 10 seconds you get. Work that must not be lost belongs in a queue, whichever setting you choose.

Two more cases decide the setting for you. A service with a GPU must use instance-based billing. And health check probes always get a CPU while they run: Google bills the probe's CPU and memory time with no request fee, so a frequent liveness probe on a request-based service is not free.

## Minimum instances and the idle rate

Minimum instances keep a number of instances started even with no traffic, so the first request after a quiet hour does not wait for a cold start. [Min instances and startup CPU boost](https://exodus.elim.io/blog/min-instances-and-startup-cpu-boost) shows how to measure that wait first. They change the bill differently under each setting.

Under request-based billing, an idle minimum instance is billed at the idle rate above: $0.0000025 per vCPU-second, a tenth of the active CPU price, plus memory at the same price as when active. One idle instance of 1 vCPU and 512 MiB costs $0.00000375 a second, or $9.86 for a 730-hour month. Under instance-based billing a minimum instance costs the full instance-based rate whether it serves anything or not, $49.93 a month for the same size.

The same rules apply to manual scaling, where you fix the number of instances yourself: idle instances are billed as idle minimum instances under request-based billing and as active instances under instance-based billing.

One trap is specific to minimum instances set per revision. A revision with its own minimum starts its instances whenever it receives a share of traffic or has a traffic tag, so an old tagged revision you forgot about keeps instances warm and billed. Set the minimum on the service with `--min`, which spreads it across the revisions that receive traffic, and remove tags you no longer use.

## Where the two prices cross

The comparison comes down to one number: the share of the month an instance is busy, meaning at least one request is in flight. Request-based billing charges more per busy second and nothing (or the idle rate) for the rest; instance-based billing charges a flat lower rate for everything.

![A line chart of monthly cost against the share of time the instance is busy. Instance-based billing is a flat line at $49.93. Request-based billing that scales to zero rises from $0 to $71.61 and crosses it at 70%; request-based with one minimum instance starts at $9.86 and crosses at 65%](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-5a1d5716a3ec5b12647e4ca4315887fa284fc769e060b4848c075bd7a039a6ef-680x350-svg/bytes "One instance of 1 vCPU and 512 MiB for a month. Below about two thirds busy, request-based billing is cheaper.")

For one instance of 1 vCPU and 512 MiB serving requests of 200 ms one at a time, at the prices above:

- Instance-based billing, one instance all month: $49.93.
- Request-based billing, scaling to zero: $7.16 at 10% busy, $17.90 at 25%, $35.81 at 50%, $53.71 at 75%, $71.61 at 100%. It costs the same as instance-based at about **70%** busy.
- Request-based billing with one minimum instance: $16.03 at 10%, $25.29 at 25%, $40.73 at 50%, $56.17 at 75%. It crosses instance-based at about **65%**.
- With long requests the request fee hardly matters and the crossing moves to about 75%.

Most web apps are far below those lines. A site with visitors in one time zone is quiet for half of each day; an internal tool is quiet on weekends; a staging copy is quiet nearly always. The services that pass 65% are steady APIs that handle traffic around the clock and workers that are fed constantly.

Concurrency moves your service along this chart. Busy time is the union of requests on an instance, so an instance that handles 20 requests at once bills one busy second where an instance that handles them one by one bills twenty. If your code can handle parallel requests, raising concurrency lowers a request-based bill more than any change of setting. [Concurrency on Cloud Run](https://exodus.elim.io/blog/concurrency-on-cloud-run) prices the same traffic at both settings, with Google's own pair of examples, and shows which web servers can take the parallel requests.

## One real service, measured

The staged copy of this site runs on Cloud Run on request-based billing, with 1 vCPU and 128 MiB. In the 24 hours to 14:24 UTC on October 11, 2026, it received 376 requests and was billed for 45.0 instance-seconds, read from Cloud Monitoring.

Over a 730-hour month that is about 1,369 billed seconds and 11,437 requests, which come to **$0.04** before the free tier and $0 after it. The same service kept up as one instance on instance-based billing would cost **$49.93** a month, and it could not even keep its size: instance-based billing needs at least 512 MiB of memory. Its busy share is 45 seconds out of 86,400, about 0.05%.

That gap, three orders of magnitude, is why request-based billing is the default and why most small services should stay on it.

## Check the setting and measure your service

The setting lives in the revision template as the annotation `run.googleapis.com/cpu-throttling`. `'true'` means request-based billing, `'false'` means instance-based, and if the annotation is missing the service is on request-based billing.

![A terminal running gcloud run services describe on the service exodus with a grep for the billing lines: cpu-throttling is 'true', minScale is '0', memory is 128Mi. Below it, the gcloud help for the cpu-throttling flag](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-48c971f3f2e652e6be00f5fc1663561eb6fd945d5914d2f324f074c29277888b-680x340-svg/bytes "Real output from Oct 11, 2026: the staged service is on request-based billing, scales to zero and has 128 MiB.")

```shell
gcloud run services describe SERVICE --region REGION \
    --format=yaml | grep -E 'cpu-throttling|minScale|maxScale|memory:|cpu:'
```

To find where your service sits on the chart, compare its billable time with the length of the period. Cloud Run exports the billable time of every service as the Cloud Monitoring metric `container/billable_instance_time` (in full, `run.googleapis.com/` and that name), in seconds. This reads the sum for the last 24 hours with the Monitoring API; the access token goes into a file readable only by you, never onto the command line:

```shell
(umask 077; gcloud auth print-access-token | sed 's/^/Authorization: Bearer /' > /tmp/auth)
curl -s -H @/tmp/auth -G \
  "https://monitoring.googleapis.com/v3/projects/PROJECT_ID/timeSeries" \
  --data-urlencode 'filter=metric.type="run.googleapis.com/container/billable_instance_time" AND resource.labels.service_name="SERVICE"' \
  --data-urlencode "interval.startTime=$(date -u -d '1 day ago' +%FT%TZ)" \
  --data-urlencode "interval.endTime=$(date -u +%FT%TZ)" \
  --data-urlencode 'aggregation.alignmentPeriod=86400s' \
  --data-urlencode 'aggregation.perSeriesAligner=ALIGN_SUM' \
  --data-urlencode 'aggregation.crossSeriesReducer=REDUCE_SUM' | grep doubleValue
rm /tmp/auth
```

Divide the number by 86,400 and by the number of instances you expect to run. A result under 0.65 says request-based billing is cheaper for that day. Look at a week, not one day; a weekly peak can change the answer. On macOS, `date -d` is GNU syntax; use `date -u -v-1d +%FT%TZ` for the start time instead.

Google also does this comparison for you. **Recommender** looks at the traffic a service received over the past month and recommends switching from request-based to instance-based billing when that would be cheaper. Recommendations usually appear about a day after a deploy, in the Cloud Run service list and in Active Assist. The recommendation goes one way only, from request-based to instance-based; nothing tells you when instance-based billing has become the dearer one, so measure again after traffic changes.

## Switch the setting

Instance-based billing needs at least 512 MiB of memory. Any change of the setting creates a new revision, and later revisions keep it until you change it again.

```shell
# instance-based billing on an existing service
gcloud run services update SERVICE --region REGION --no-cpu-throttling --memory 512Mi

# back to request-based billing
gcloud run services update SERVICE --region REGION --cpu-throttling

# or at deploy time
gcloud run deploy SERVICE --image IMAGE_URL --region REGION --no-cpu-throttling
```

In a service YAML file (`gcloud run services describe SERVICE --format export > service.yaml`, then `gcloud run services replace service.yaml`), the setting is the revision template annotation `run.googleapis.com/cpu-throttling: 'false'`. In Terraform or OpenTofu, on a `google_cloud_run_v2_service`, it is `cpu_idle = false` in the container's `resources` block; `true` is request-based.

After a switch to instance-based billing, autoscaling still runs. Cloud Run then scales on the CPU the instances use for their whole life, not only during requests, except when it scales to and from zero, which it decides on requests alone. Set `--max-instances` on every service either way; Google calls it the cost-safety baseline, and on instance-based billing every extra instance is billed for every second it lives.

## Commitments make instance-based billing cheaper still

If a service will run around the clock for a year or more, committed use discounts lower the price of the setting you are on. A commitment is an hourly spend you promise for one or three years, bought for a whole billing account and billed monthly whether you use it or not; it cannot be canceled.

- **Request-based billing:** 17% off with a one-year or a three-year commitment.
- **Instance-based billing, jobs and worker pools:** 17% off with a one-year Cloud Run commitment, 28% off with a one-year Compute flexible commitment, 46% off with a three-year one. Flexible commitments also cover Compute Engine and GKE, in any region.

For the instance of 1 vCPU and 512 MiB above, $49.93 a month on demand becomes $35.95 with a one-year flexible commitment and $26.96 with a three-year one. A commitment does not cover GPUs or network traffic, and it only pays when the service really runs every hour. Commit to what has run steadily for a few months, not to an estimate.

## Jobs, worker pools and instances

The choice exists only for services. Everything else on Cloud Run has one way of billing, and [services, jobs and worker pools](https://exodus.elim.io/blog/cloud-run-services-jobs-and-worker-pools) says when to use which:

- **Jobs** are always billed at the instance-based rates, $0.000018 per vCPU-second and $0.000002 per GiB-second, for the whole life of each task's instance, with a minimum of one minute per instance. A job that runs 10 seconds pays for 60.
- **Worker pools** always have a CPU and are billed for every second their instances run, at their own lower prices: $0.000011244 per vCPU-second and $0.000001235 per GiB-second.
- **Instances**, the Preview resource for one long-lived container, are billed for their lifetime on shared CPU.

So a background worker that must always run is usually cheaper as a worker pool than as an instance-billed service with a minimum instance: $31.17 against $49.93 a month for 1 vCPU and 512 MiB. A worker that only drains a queue now and then is cheaper as Cloud Tasks calling a request-billed service, or as a job.

## How to choose

![A decision diagram. If code runs outside a request, such as work after the response, timers, threads or a GPU, choose instance-based billing. If an instance is busy more than about 65 to 70 percent of the time every day, choose instance-based and price a committed use discount. Otherwise stay on request-based billing, the default, adding one minimum instance only if cold starts hurt](https://exodus.elim.io/media/v2026-09-16/t/exodus/assets/image-bdfeeedc8820ee41a62409cda4428cc53c37a0945cd2f0bf40eaa374981ff0aa-680x370-svg/bytes "Two questions decide the setting for almost every service.")

1. **Does code run outside a request?** If it does, and you cannot move that work into Cloud Tasks, Cloud Scheduler or a job, use instance-based billing with at least one minimum instance. A GPU service has no choice: it is instance-based.
1. **Is an instance busy most of the time, every day?** Above about 65-70% busy, instance-based billing is cheaper; check with the billable time metric or wait for Recommender, then price a commitment.
1. **Otherwise stay on request-based billing.** If the first request after a quiet period is too slow, add one minimum instance with `--min 1`: on request-based billing it costs $9.86 a month at 1 vCPU and 512 MiB while idle, a fifth of what the same instance costs on instance-based billing.

This is the question an Exodus audit asks of every part of an app. It searches the code for work after the response and in-process timers, the patterns that need a CPU between requests, and its plan replaces them with Cloud Tasks, Cloud Scheduler and jobs, so the web service can stay on request-based billing.

## Checklist

- Read the setting: `gcloud run services describe SERVICE --format=yaml | grep cpu-throttling`. Missing or `'true'` is request-based.
- Find code that runs after the response, in timers or in background threads. Move it to Cloud Tasks, Cloud Scheduler or a job, or switch to instance-based billing with a minimum instance.
- Measure the busy share from `container/billable_instance_time` over a week. Under 65%, request-based billing is cheaper.
- Raise concurrency if your code handles parallel requests; it cuts request-based busy time.
- Before switching to instance-based billing, set memory to at least 512 MiB and set `--max-instances`.
- Keep minimum instances on the service (`--min`), not on revisions, and remove unused traffic tags.
- For an always-on worker, price a worker pool before an instance-billed service.
- Commit only to spend that has run steadily for months: 17% off on request-based, up to 46% off on instance-based.

## FAQ

### What do "CPU always allocated" and "CPU only allocated during request processing" mean on Cloud Run?

They are the old names of the two billing settings. "CPU only allocated during request processing" is now request-based billing, the default, and "CPU always allocated" is instance-based billing. In gcloud the flags are still named after the CPU: cpu-throttling for request-based and no-cpu-throttling for instance-based.

### Why do background tasks stall on Cloud Run?

On request-based billing an idle instance keeps its memory but gets almost no CPU, so work after the response, in-process timers and background threads stop until the next request arrives. Move the work into requests with Cloud Tasks, Cloud Scheduler or a job, or switch to instance-based billing with at least one minimum instance.

### How much does a minimum instance cost on Cloud Run?

One idle minimum instance of 1 vCPU and 512 MiB costs $9.86 for a 730-hour month on request-based billing, at the idle rate of $0.0000025 per vCPU-second and per GiB-second. On instance-based billing the same instance costs the full rate whether it serves anything or not, $49.93 a month.

### Do Cloud Run jobs and worker pools have a billing setting?

No. Jobs are always billed at the instance-based rates for the whole life of each task's instance, with a minimum of one minute, so a 10-second job pays for 60. Worker pools always have a CPU and are billed every second at lower prices: $31.17 a month for 1 vCPU and 512 MiB.

## Sources

1. [Billing settings for services, Google (updated Oct 7, 2026, read Oct 11, 2026)](https://docs.cloud.google.com/run/docs/configuring/billing-settings)
2. [Cloud Run pricing, Google (prices, billable instance time, pricing examples; read Oct 11, 2026)](https://cloud.google.com/run/pricing)
3. [Container runtime contract, Google (instance lifecycle, 15-minute idle, SIGTERM; read Oct 11, 2026)](https://docs.cloud.google.com/run/docs/container-contract)
4. [Set minimum instances for services, Google (read Oct 11, 2026)](https://docs.cloud.google.com/run/docs/configuring/min-instances)
5. [Manual scaling for services, Google (read Oct 11, 2026)](https://docs.cloud.google.com/run/docs/configuring/services/manual-scaling)
6. [About instance autoscaling in Cloud Run services, Google (read Oct 11, 2026)](https://docs.cloud.google.com/run/docs/about-instance-autoscaling)
7. [Best practices for cost-optimized Cloud Run services, Google (updated Oct 7, 2026)](https://docs.cloud.google.com/run/docs/tips/services-cost-optimization)
8. [Optimize Cloud Run services with Recommender, Google (updated Oct 9, 2026)](https://docs.cloud.google.com/run/docs/recommender)
9. [Compute flexible committed use discounts for Cloud Run, Google (updated Oct 9, 2026)](https://docs.cloud.google.com/run/cud)
10. [Container health checks, Google (probe billing; read Oct 11, 2026)](https://docs.cloud.google.com/run/docs/configuring/healthchecks)
11. [Deployment options and resource model, Google (jobs, worker pools, instances billing; read Oct 11, 2026)](https://docs.cloud.google.com/run/docs/resource-model)
12. [gcloud run services update and gcloud run deploy --help, Google Cloud SDK 587.0.0 (run Oct 11, 2026)](https://docs.cloud.google.com/sdk/gcloud/reference/run/services/update)
13. [Cloud Run metrics: container/billable_instance_time, Google (read Oct 11, 2026)](https://docs.cloud.google.com/monitoring/api/metrics_gcp)
14. Exodus team: the staged Exodus site's Cloud Run service, 376 requests and 45.0 billable instance-seconds in the 24 hours to 14:24 UTC on Oct 11, 2026, read from Cloud Monitoring