A Cloud Run bill can look mysterious when a service receives few requests but still needs to do work after responding. The root problem is often a mix of three decisions: when CPU is available, how long an instance should exist, and whether an HTTP service is the right resource for the work.

The Google Cloud Run introduction explains the platform broadly. This article answers the narrower choice: when should you use request-based billing, and when should you use instance-based billing?

I did not run a Cloud Run service or measure a specific application for this article. The comparison uses current Google Cloud documentation, public discussions to identify recurring questions, and an original decision matrix. The commands are configuration references, not proof of an outcome in your project.

Diagram comparing request-based billing, with CPU during requests, and instance-based billing, with CPU during the instance lifecycle.

Short answer

  • Use request-based billing when the work is tied to request processing and traffic is sporadic, bursty, or variable.
  • Use instance-based billing when the application truly needs CPU for the whole instance lifecycle, including bounded background work.
  • Do not choose the mode from the word “billing” alone. Confirm whether the work belongs in a Service, Job, worker pool, or Cloud Run instance.
  • Measure cost, latency, shutdowns, and unfinished work after changing one variable at a time.

What is the difference between the two modes?

The Cloud Run billing settings documentation, retrieved October 28, 2026, says that request-based billing allocates CPU while requests are being processed. Instance-based billing keeps CPU allocated for the entire instance lifecycle.

That difference also changes what happens when there is no active request. With request-based billing, idle capacity does not keep processing background work with allocated CPU. With instance-based billing, the instance remains in a billed lifecycle while it exists, including when it is idle. Cloud Run pricing, retrieved the same day, describes the distinction between request-processing time and instance lifetime.

Question Request-based billing Instance-based billing
When is CPU allocated? During request processing During the instance lifecycle
Typical traffic Sporadic, bursty, or variable Continuous, slow, or paired with work beyond the request
What happens while idle? The service can scale and does not process background work with allocated CPU The instance remains in its billed lifecycle while it exists
Work that deserves attention APIs and request-bound handlers Bounded background work, telemetry agents, and application work started during the lifecycle
Decision risk Paying for capacity you do not need Paying for idle instances or using a Service as a durable worker

The mode is not automatically cheap or expensive. It is a statement about the lifecycle your application needs.

When is request-based billing the better choice?

Request-based billing usually fits an API that does its important work during the request and finishes most of that work before responding. It also fits traffic that varies substantially and can benefit from scaling from zero. If the first request is the concern, compare this choice with the Cloud Run cold-start diagnosis.

Google Cloud recommends this mode for sporadic, bursty, or spiky workloads in the billing settings documentation. That is a workload recommendation, not a universal price estimate. Actual cost depends on usage, region, configuration, and related resources.

Choose this path when all of these are true:

  1. The important work happens during a request.
  2. The process does not need reliable CPU after sending the response.
  3. The delay from scaling from zero fits the route's objective.
  4. The service can retry the operation or persist its state without depending on the current process staying alive.

That does not make request-based billing safe for every short endpoint. If a route starts asynchronous work and returns success before persisting a durable unit of work, the problem is workflow reliability, not only billing.

When does instance-based billing solve a real problem?

Instance-based billing makes sense when work needs CPU outside the strict request-processing window. Google Cloud's documentation cites limited asynchronous or background work after the response, including OpenTelemetry agents, asynchronous Node.js work, Java threads, and Kotlin coroutines.

It can also fit steady traffic or an application that does background work while the instance exists. The important phrase is “while the instance exists.” Autoscaling still applies. Cloud Run can terminate instances, and an idle instance can remain for no more than 15 minutes after a request unless other settings, such as minimum instances, apply (Google Cloud, “Billing settings for services”, retrieved October 28, 2026).

Choose instance-based billing only when you can also answer these questions:

  • What happens if the instance is terminated during the work?
  • What durable state lets the next instance resume or retry the unit of work?
  • What cost limit prevents idle instances from growing without control?
  • Why does this work belong in an HTTP Service instead of a Cloud Run Job with retries, a worker pool, or another resource?

Instance-based billing provides CPU during the instance lifecycle. It does not provide a queue, checkpoint, retry policy, mutual exclusion, or a promise that the instance will remain alive.

What does the mode not guarantee?

Four recurring confusions can turn a billing change into a false fix.

A live instance is not a continuity guarantee

Autoscaling, deployments, startup failures, regional capacity, and quota still affect the lifecycle. Minimum instances can reduce the chance of starting from zero, but they are a capacity target, not a promise that a particular instance will stay alive.

Allocated CPU does not make work durable

If the process is terminated, the instance's memory and writable filesystem are not a checkpoint for the next instance. Persist state in durable storage and use an idempotency key when the unit can be repeated. The article on handling SIGTERM in Cloud Run without losing work covers that handoff.

A 504 does not tell you by itself whether work finished

The Cloud Run request timeout documentation, retrieved October 28, 2026, says the default timeout is 300 seconds, the documented maximum is 3600 seconds, and a 504 closes the connection even though the container may continue processing the interrupted request. That requires idempotency and a way to verify state outside the connection.

Do not increase the timeout to hide a queue, a slow dependency, or work that should be a Job. A larger timeout changes the request limit, but it does not create a distributed transaction.

Health checks can change the decision

Cloud Run's billing documentation says health checks require instance-based billing. The explanation of Cloud Run startup, liveness, and readiness checks helps separate a probe's purpose from its billing mode. If a probe needs CPU outside ordinary request processing, treat that as a technical requirement to validate alongside cost.

Service, Job, worker pool, or instance?

Choose the owner of the work lifecycle before choosing billing. The Cloud Run deployment options and resource model, retrieved October 28, 2026, helps separate services, jobs, worker pools, and instances.

Work shape Resource to investigate first Why not start with billing?
Short HTTP response tied to the request Cloud Run Service The lifecycle ends with the request and can scale with traffic
Finite batch that should finish and can be retried Cloud Run Job The job expresses execution, tasks, and retries
Continuous queue consumption without a public endpoint Cloud Run worker pool The model represents the worker without turning an API into an improvised queue
Long-running process that needs a specific instance Cloud Run instance The instance lifecycle is the object you are trying to operate

A Service with instance-based billing can be useful for a limited case, such as an application that starts controlled background work. It is a poor choice when it only keeps a worker alive without a queue, checkpoint, and shutdown policy.

How do you change the mode and verify the revision?

Cloud Run's billing documentation gives these commands for a service:

gcloud run services update SERVICE --cpu-throttling
gcloud run services update SERVICE --no-cpu-throttling
gcloud run services describe SERVICE --region REGION

--cpu-throttling selects request-based behavior. --no-cpu-throttling selects instance-based behavior. The change creates a new revision, and instance-based billing requires at least 512 MiB of memory according to the same documentation.

The third command does not prove that cost improved. Use it to inspect the revision configuration and record the region, CPU, memory, concurrency, minimum instances, and image. If the problem appears during peaks, separate billing from Cloud Run concurrency per instance. Then compare the same traffic scenario across revisions.

Run a small, reversible check:

  1. Choose a route or workload that represents the problem.
  2. Record requests, errors, latency, instance count, and cost for the comparison period.
  3. If there is asynchronous work, record start, checkpoint, and completion outside the container.
  4. Change only the CPU and billing mode.
  5. Check whether background work finished, was safely retried, or was abandoned.
  6. Roll back the revision if the objective does not improve or cost grows without an operational reason.

Do not use an artificial keep-alive to prevent scale-to-zero without measuring its effect. A periodic request can change traffic and make cost attribution harder.

Decision checklist

Ask these questions before changing the setting:

  • Does the unit of work need to continue after the response is sent?
  • Is there durable state that allows the work to be retried or resumed?
  • Is traffic sporadic, bursty, continuous, or unknown?
  • Can an idle instance keep being billed within the budget?
  • Does a health check or another requirement truly need CPU outside requests?
  • Would a Job or worker pool express the lifecycle better than a Service?
  • Will the new revision be compared with the old one using the same metric?

If you cannot answer the first two questions, you are not yet facing a billing choice. You are facing a work and state design problem.

Conclusion

Request-based billing fits request-bound work and traffic that can scale from zero. Instance-based billing fits CPU needed throughout the instance lifecycle, including some bounded asynchronous work. Neither mode creates durability, a queue, or persistence.

Start with the work lifecycle. Then choose a Service, Job, worker pool, or instance. Only then change billing, compare one revision with another, and check cost alongside whether the work actually completed.

How this analysis was made

Samuel Fajreldines is the author responsible for this article. The research compared current Cloud Run documentation, the local post inventory to avoid intent overlap, and public practitioner discussions to identify questions and language. The decision matrix is original editorial synthesis. The commands were not run against a Cloud Run project for this article, and there is no benchmark, client case, or calculated price. AI assistance supported discovery, drafting, image generation, localization, and consistency review; it did not supply production experience or replace source verification.

Sources consulted