This page describes billing settings assuming the use of the default Cloud Run [autoscaling](https://docs.cloud.google.com/run/docs/about-instance-autoscaling.md.txt) behavior. See [Billing behavior using manual scaling](https://docs.cloud.google.com/run/docs/configuring/services/manual-scaling.md.txt#cpu-allocation-and-billing) for additional considerations if you use manual scaling. There are two billing settings in Cloud Run services: - **Request-based billing** (default): Cloud Run service instances are only charged when they process requests, when they start, and when they shut down. See [instance lifecycle](https://docs.cloud.google.com/run/docs/reference/container-contract#lifecycle) for more details. This setting was previously called *CPU only allocated during request processing*. - **Instance-based billing** : Cloud Run service instances are charged for the entire lifecycle of each instance, even when there are no incoming requests. Instance-based billing can be useful for running short-lived background tasks and other asynchronous processing tasks. This setting was previously called *CPU always allocated*. If you choose request-based billing, you are charged per request and only when the instance processes a request. If you choose instance-based billing, you are charged for the entire lifecycle of the instance. See the [Cloud Run pricing tables](https://cloud.google.com/run/pricing#tables) for details. [Recommender](https://docs.cloud.google.com/run/docs/recommender.md.txt#optimize-billing) automatically looks at traffic received by your Cloud Run service over the past month, and will recommend switching from *request-based billing* to *instance-based billing*, if this is cheaper. Unlike Cloud Run services, all [Cloud Run jobs](https://docs.cloud.google.com/run/docs/create-jobs.md.txt) use instance-based billing. [Cloud Run worker pools](https://docs.cloud.google.com/run/docs/deploy-worker-pools.md.txt) and [Cloud Run instances](https://docs.cloud.google.com/run/docs/instances/create-and-manage-instances.md.txt) are also billed for the entire lifecycle of each instance using their own dedicated [pricing SKUs](https://cloud.google.com/run/pricing#tables). For a comparison across resource types, see [Cloud Run resource comparison](https://docs.cloud.google.com/run/docs/resource-model.md.txt#resource-comparison). ## CPU allocation impact Selecting a billing setting impacts how CPU is allocated. - With *request-based billing*, CPU is only allocated during request processing. - With *instance-based billing*, CPU is allocated for the entire container instance lifecycle. ## Budget spend caps When you configure Cloud Billing Budget [spend caps](https://docs.cloud.google.com/billing/docs/how-to/budgets-spend-caps.md.txt) in the Cloud Billing console or programmatically using the [Cloud Billing Budget API](https://docs.cloud.google.com/billing/docs/how-to/budget-api-spend-cap.md.txt), those caps automatically apply to all Cloud Run resource types in your project. You can monitor your spend cap progress directly from the [Cloud Run console](https://console.cloud.google.com/run/) overview page. When you hit a spend cap, Google Cloud pauses all Cloud Run workloads to prevent further costs to the following Cloud Run resources: - Services: any existing service will fail to serve traffic and return `5xx` errors. - Jobs: new task executions fail to start, and in-progress tasks fail to complete. - Worker pools: any existing instances stop processing tasks. - [Instances](https://docs.cloud.google.com/run/docs/instances/create-and-manage-instances.md.txt): any running instances shut down, new instances or restarts fail to start, and requests to instance URLs return `5xx` errors. If you exceed your spend cap, you'll receive an alert notification and see an enforcement banner in the [Cloud Run console](https://console.cloud.google.com/run/). Enforced spend caps reset at the start of each month on the first day of the next billing cycle, unblocking your workloads and setting the spend amount to zero. If you exceed your spend cap and want to resume operations before the monthly reset, manually adjust or lift the cap in the Cloud Run console overview page. > [!NOTE] > **Note:** Compute Engine bills VPC connector VMs, so Cloud Run spend caps ignore them. If you want spend caps to fully cover egress networking, use [Direct VPC egress](https://docs.cloud.google.com/run/docs/configuring/vpc-direct-vpc.md.txt). ## How to choose the appropriate billing setting Choosing the appropriate billing setting for your use case depends on several factors, such as traffic patterns, background execution, and cost, each of which is described in the following sections. > [!NOTE] > **Note:** There is no container-based way to tell whether an instance changes from idle to actively serving. If detecting this kind of change is an issue for you, you should choose *instance-based billing*. ### Traffic patterns considerations - *Request-based billing* is recommended when incoming traffic is sporadic, bursty or spiky. - *Instance-based billing* is recommended when incoming traffic is steady, slowly varying. ### Background execution considerations Selecting *instance-based billing* allocates CPU even outside of request processing, letting you execute short-lived background tasks and other asynchronous processing work after returning responses. For example: - Leveraging monitoring agents like OpenTelemetry that may assume to be able to run in the background. - Using Go's Goroutines, Node.js async, Java threads, and Kotlin coroutines. - Using application frameworks that rely on built-in scheduling or background functionalities. Idle instances, including those kept warm using [minimum instances](https://docs.cloud.google.com/run/docs/configuring/min-instances.md.txt), can be shut down at any time. If you need to finish outstanding tasks before the container is terminated, you can trap SIGTERM to give a instance 10 seconds grace time before it is stopped. Consider using Cloud Tasks for [executing asynchronous tasks](https://docs.cloud.google.com/run/docs/triggering/using-tasks.md.txt). Cloud Tasks automatically retries failed tasks and supports running times up to 30 minutes. If your workload requires a single, long-lived instance that runs continuously for hours or days without horizontal autoscaling, deploy a [Cloud Run instance](https://docs.cloud.google.com/run/docs/instances/create-and-manage-instances.md.txt) instead of a service. Unlike service instances, which scale down after at most 15 minutes of idle time, a Cloud Run instance can run uninterrupted for up to 7 days and supports configurable [restart policies](https://docs.cloud.google.com/run/docs/configuring/instances/restart-policy.md.txt). This makes Cloud Run instances well-suited for personal AI agents, stateful workflow engines, and remote development environments. See [When to use Cloud Run instances](https://docs.cloud.google.com/run/docs/overview/what-is-cloud-run.md.txt#instances-use-cases) and [Cloud Run instance lifecycle](https://docs.cloud.google.com/run/docs/instances/instance-lifecycle.md.txt) for details. ### Cost considerations If you are using *request-based billing* , *instance-based billing* can be more economical if: - Your Cloud Run service is processing high number of current requests at a rather steady rate. - You don't see a lot of "idle" instances when looking at the [instance count metric](https://docs.cloud.google.com/run/docs/monitoring.md.txt). You can use the [pricing calculator](https://cloud.google.com/products/calculator) to estimate cost differences. If you only need a single continuously running instance without horizontal autoscaling, a [Cloud Run instance](https://docs.cloud.google.com/run/docs/instances/create-and-manage-instances.md.txt) can cost less than a service with [minimum instances](https://docs.cloud.google.com/run/docs/configuring/min-instances.md.txt) and instance-based billing. Cloud Run instances have their own [pricing SKUs](https://cloud.google.com/run/pricing#tables) and support a [shared CPU model with burst capacity](https://docs.cloud.google.com/run/docs/configuring/instances/cpu.md.txt#burst-throttling) (6.25% baseline vCPU with bursting up to 100%), lowering continuous costs for mostly idle singleton workloads. ### Autoscaling considerations Cloud Run by default [autoscales](https://docs.cloud.google.com/run/docs/about-instance-autoscaling.md.txt) the number of container instances. For a service set to *request-based billing*, Cloud Run autoscales the number of instances based on CPU utilization only during request processing. For a service set to *instance-based billing* , Cloud Run autoscales the number of instances based on CPU utilization for the entire lifecycle of the container instance, except when [scaling to and from zero](https://docs.cloud.google.com/run/docs/about-instance-autoscaling.md.txt#instance-based-billing), where it only uses requests. See [manual scaling](https://docs.cloud.google.com/run/docs/configuring/services/manual-scaling.md.txt) for additional considerations if you use manual scaling instead of the Cloud Run autoscaling feature. ### Instance-based billing considerations Even if the billing setting is set to *instance-based billing* , Cloud Run [autoscaling](https://docs.cloud.google.com/run/docs/about-instance-autoscaling.md.txt) is still in effect, and may terminate instances if they aren't needed to handle incoming traffic or current CPU utilization outside of requests. An instance will never stay idle for more than 15 minutes after processing a request unless it is kept active using [minimum instances](https://docs.cloud.google.com/run/docs/configuring/min-instances.md.txt). Combining instance-based billing with a number of [minimum instances](https://docs.cloud.google.com/run/docs/configuring/min-instances.md.txt) results in a number of instances up and running with full access to CPU resources, enabling background processing use cases. When using this pattern, Cloud Run applies [instance autoscaling](https://docs.cloud.google.com/run/docs/about-instance-autoscaling.md.txt) even if a service is using CPU outside of any requests. Use a service with instance-based billing and [minimum instances](https://docs.cloud.google.com/run/docs/configuring/min-instances.md.txt) when your background or agentic workload needs to autoscale beyond a single instance during peak load. For other background patterns, consider these Cloud Run resources: - **Single-instance, long-lived workloads** : Use a [Cloud Run instance](https://docs.cloud.google.com/run/docs/instances/create-and-manage-instances.md.txt) if you only need a single instance with direct start, stop, and restart lifecycle control and no autoscaling. - **Non-HTTP pull-based workloads** : Use a [Cloud Run worker pool](https://docs.cloud.google.com/run/docs/deploy-worker-pools.md.txt) for continuous background consumers, such as Pub/Sub or Kafka workers, that don't require an HTTP endpoint. If you use healthcheck probes, you must use instance-based billing for every probe. See [container healthcheck probes](https://docs.cloud.google.com/run/docs/configuring/healthchecks.md.txt#billing) for billing details. ## Required roles To get the permissions that you need to configure and deploy Cloud Run services, ask your administrator to grant you the following IAM roles: - [Cloud Run Developer](https://docs.cloud.google.com/iam/docs/roles-permissions/run.md.txt#run.developer) (`roles/run.developer`) on the Cloud Run service - [Service Account User](https://docs.cloud.google.com/iam/docs/roles-permissions/iam.md.txt#iam.serviceAccountUser) (`roles/iam.serviceAccountUser`) on the service identity If you are deploying a [service](https://docs.cloud.google.com/run/docs/deploying-source-code.md.txt#required_roles) or [function](https://docs.cloud.google.com/run/docs/deploy-functions.md.txt#required-roles) from source code, you must also have additional roles granted to you on your project and Cloud Build service account. For a list of IAM roles and permissions that are associated with Cloud Run, see [Cloud Run IAM roles](https://docs.cloud.google.com/run/docs/reference/iam/roles.md.txt) and [Cloud Run IAM permissions](https://docs.cloud.google.com/run/docs/reference/iam/permissions.md.txt). If your Cloud Run service interfaces with Google Cloud APIs, such as Cloud Client Libraries, see the [service identity configuration guide](https://docs.cloud.google.com/run/docs/configuring/services/service-identity.md.txt). For more information about granting roles, see [deployment permissions](https://docs.cloud.google.com/run/docs/reference/iam/roles.md.txt#additional-configuration) and [manage access](https://docs.cloud.google.com/iam/docs/granting-changing-revoking-access.md.txt). ## Set and update billing Any configuration change leads to the creation of a new revision. Subsequent revisions will also automatically get this configuration setting unless you make explicit updates to change it. If you select instance-based billing, you must specify at least 512MiB of [memory](https://docs.cloud.google.com/run/docs/configuring/services/memory-limits.md.txt). You can change the billing setting using the Google Cloud console, the gcloud CLI, or a YAML file when you [create a new service](https://docs.cloud.google.com/run/docs/deploying.md.txt#service) or [deploy a new revision](https://docs.cloud.google.com/run/docs/deploying.md.txt#revision): ### Console 1. In the Google Cloud console, go to Cloud Run: [Go to Cloud Run](https://console.cloud.google.com/run) 2. Select **Services** from the Cloud Run navigation menu: 1. If you are configuring a new service, click **Deploy container** and fill out the initial service settings page. 2. If you are configuring an existing service, click the service, then click the **Scaling** tab. 3. Under **Billing** , select **Request-based** for your instances to be charged only during request processing, or select **Instance-based** for your instances to be charged for the entire lifetime of instances. 4. Click **Create** for a new service. Click **View diff \& redeploy** , then **Deploy changes** for an existing service. ### gcloud You can [update the billing setting](https://docs.cloud.google.com/sdk/gcloud/reference/run/services/update.md.txt). To set instance-based billing for a given service:
```bash gcloud run services update SERVICE --no-cpu-throttling ```
Replace SERVICE with the name of your service. To set request-based billing:
```bash gcloud run services update SERVICE --cpu-throttling ```
You can also set your billing setting during [deployment](https://docs.cloud.google.com/sdk/gcloud/reference/run/deploy.md.txt). To set your billing setting to instance-based billing:
```bash gcloud run deploy --image IMAGE_URL --no-cpu-throttling ```
To set your billing setting to request-based billing:
```bash gcloud run deploy --image IMAGE_URL --cpu-throttling ```
Replace `IMAGE_URL` with a reference to the container image, for example, `us-docker.pkg.dev/cloudrun/container/hello:latest`. If you use Artifact Registry, the [repository](https://docs.cloud.google.com/artifact-registry/docs/repositories/create-repos.md.txt#docker) REPO_NAME must already be created. The URL follows the format of `LOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG` . ### YAML 1. If you are creating a new service, skip this step. If you are updating an existing service, download its [YAML configuration](https://docs.cloud.google.com/run/docs/reference/yaml/v1.md.txt): ```bash gcloud run services describe SERVICE --format export > service.yaml ``` 2. Update the `cpu` attribute: ```yaml apiVersion: serving.knative.dev/v1 kind: Service metadata: name: SERVICE spec: template: metadata: annotations: run.googleapis.com/cpu-throttling: 'BOOLEAN' name: REVISION ``` Replace the following: - SERVICE: the name of your Cloud Run service - BOOLEAN: `true` to set request-billing, or `false` to set instance-based billing. - `REVISION`: a new revision name or delete it (if present). If you supply a new revision name, it **must** meet the following criteria: - Starts with `SERVICE-` - Contains only lowercase letters, numbers and `-` - Does not end with a `-` - Does not exceed 63 characters 3. Create or update the service using the following command: ```bash gcloud run services replace service.yaml ``` The `gcloud run services replace` command defaults to using `service.yaml` file if present. ### Terraform To learn how to apply or remove a Terraform configuration, see [Basic Terraform commands](https://docs.cloud.google.com/docs/terraform/basic-commands.md.txt). Add the following to a [`google_cloud_run_v2_service`](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/cloud_run_v2_service) resource in your Terraform configuration:
```terraform resource "google_cloud_run_v2_service" "default" { name = "cloudrun-service-cpu-allocation" location = "us-central1" deletion_protection = false # set to "true" in production template { containers { image = "us-docker.pkg.dev/cloudrun/container/hello" resources { # If true, garbage-collect CPU when once a request finishes cpu_idle = false } } } } ``` ## View billing settings To view the current billing settings for your Cloud Run service: ### Console 1. In the Google Cloud console, go to the Cloud Run **Services** page: [Go to Cloud Run](https://console.cloud.google.com/run/services) 2. Click the service to open the **Service details** page. 3. Click the **Scaling** tab to find the **Billing** setting. ### gcloud 1. Run the following command to view the billing configuration: ```bash gcloud run services describe SERVICE --format=yaml ``` 2. In the YAML output, find the `run.googleapis.com/cpu-throttling` setting. A value of `false` indicates instance-based billing, and if this setting is missing, it indicates request-based billing.