Cloud Run Scaling Explained: Cold Starts, Min Instances, Max Instances, and Concurrency

Simple explanation

Cloud Run runs your container image and routes HTTP traffic to it. When more requests arrive than your current instances can handle, Cloud Run starts new instances. When traffic drops and instances sit idle, they are stopped. With the default configuration, a service that receives no traffic eventually has zero running instances. That is scale-to-zero.

The three numbers you control are:

• Minimum instances: the floor. How many instances stay running even at zero traffic.
• Maximum instances: the ceiling. How many instances Cloud Run is allowed to start.
• Concurrency: how many simultaneous requests a single instance handles before Cloud Run starts another one.

How Cloud Run scaling works

When a request arrives at your Cloud Run service, Google’s load balancer sends it to an available instance. Cloud Run tracks how many requests each instance is currently handling. When that number approaches the concurrency limit, Cloud Run starts a new instance rather than queue the request against an already-busy one.

New instances go through a cold start: Cloud Run pulls any uncached container image layers from Artifact Registry, starts the container process, and waits for your application to bind to the PORT environment variable and signal readiness. Only then can the instance accept traffic. This window (image pull to ready) is the cold start latency added to the request that triggered the new instance.

When traffic drops and instances fall below their concurrency threshold, Cloud Run marks them idle. After a cooldown window, idle instances are stopped. If min-instances is 0 and the service fully drains, all instances are eventually terminated and the service scales to zero.

The next request to arrive after scale-to-zero waits for a full cold start before getting a response. This is the fundamental trade-off: scale-to-zero saves money at idle, but the first request pays a latency penalty.

Key scaling controls

Minimum instances

Minimum instances sets the number of container instances that stay running even when there is no traffic. The default is 0, which enables scale-to-zero.

Setting —min-instances=1 keeps one warm instance ready at all times. The first request after any idle period hits a ready container instead of waiting for startup.

Setting —min-instances=2 or higher also helps during rolling deployments. When you push a new revision, Cloud Run replaces instances gradually. With only one minimum instance, there is a brief window where the old instance is stopping and the new one is not yet warm. Two minimum instances removes that gap. See CI/CD pipelines for Cloud Run for how deployment strategies interact with instance configuration.

Maximum instances

Maximum instances caps how many container instances Cloud Run is allowed to run simultaneously. Without a cap, Cloud Run can scale to hundreds of instances under an unexpected traffic spike. That is often not a billing problem first. It is a downstream problem.

The most common failure mode is database connection exhaustion. If each Cloud Run instance opens one database connection and your database accepts 100 connections, then instance 101 causes connection errors that cascade into 500 responses across your entire service. Set —max-instances based on what your database or upstream services can handle, not on an estimate of expected traffic.

When max-instances is reached and all instances are at concurrency capacity, Cloud Run queues incoming requests briefly. If the queue overflows or requests time out, Cloud Run returns HTTP 429. Design your clients to handle this gracefully.

Concurrency

Concurrency is the maximum number of simultaneous HTTP requests a single container instance handles. The default is 80. The maximum is 1000.

For I/O-bound services (APIs that spend most of their time waiting on database responses or external HTTP calls), high concurrency is efficient. One instance handles 80 requests simultaneously, most of which are just waiting on I/O. The instance is not CPU-saturated; it is managing many open connections at once.

For CPU-bound services such as image processing, PDF generation, video transcoding, and machine learning inference, high concurrency causes contention. Each request consumes real CPU. Lowering concurrency to 1 to 5 means each instance handles fewer simultaneous requests, giving each one more CPU share and more predictable latency.

Setting concurrency to 1 makes Cloud Run behave like traditional serverless functions: one request per instance. This maximises isolation but also maximises instance count and cold start exposure under load. Only use concurrency of 1 if your workload genuinely requires it, such as when requests share global mutable state within the process.

CPU allocation and startup behaviour

Cloud Run has two CPU allocation modes:

• CPU allocated during requests only (default): CPU is available and billed only while a request is active. Idle instances have their CPU throttled. Most HTTP services have nothing to do between requests; this mode is both cost-efficient and correct for them.

• CPU always allocated: CPU is available even between requests. Required if your application needs to run background processing, polling loops, or cache warmup logic outside of request handlers. Billed continuously while any instance is running.

The —cpu-boost flag is separate from CPU allocation mode. It temporarily allocates extra CPU during container startup to help your application initialise faster. This reduces cold start latency at the cost of slightly higher billing for those startup seconds. It is worth enabling for most services that have meaningful cold start times.

# Deploy with all key scaling parameters
gcloud run deploy my-service \
  --image=IMAGE \
  --region=us-central1 \
  --min-instances=1 \
  --max-instances=50 \
  --concurrency=80 \
  --cpu-boost

# Update scaling on a running service
gcloud run services update my-service \
  --region=us-central1 \
  --min-instances=2 \
  --max-instances=100

# Enable CPU always allocated for background processing
gcloud run services update my-service \
  --region=us-central1 \
  --no-cpu-throttling

# Set concurrency to 1 for CPU-bound or fully isolated workloads
gcloud run services update my-service \
  --region=us-central1 \
  --concurrency=1

How to choose Cloud Run scaling settings

The right configuration depends on what your service does and who calls it. These scenarios cover the most common cases.

CPU-heavy workloads should start with concurrency of 1 and tune upward only after measuring. Use the CPU utilisation metrics visible in Cloud Run monitoring to check whether instances are CPU-saturated under real load before raising concurrency.

Spiky workloads such as triggered batch jobs, marketing email sends, and event-driven pipelines benefit from min-instances=0 for cost savings and a high enough max-instances to absorb bursts. Cold starts are acceptable here because callers are automated processes, not users waiting for a page load.

When you deploy a new Cloud Run service, start with the defaults and measure. Real traffic data is more reliable than estimates when tuning these settings.

When scaling settings actually matter

For many services, the defaults are fine. Scaling settings become critical in these situations:

• Your service is user-facing. Cold starts adding one to three seconds to a page load are noticeable. Set min-instances to 1 or higher.

• You have strict latency SLOs. P99 latency targets are broken by cold starts. Even a handful per hour will show up in tail latency metrics.

• You share a downstream database. Without a max-instances cap, a traffic spike can instantly exhaust database connections. This is the most common scaling misconfiguration in production Cloud Run deployments.

• Your traffic is highly spiky. A service that jumps from 0 to 500 requests per second triggers many simultaneous cold starts. CPU boost and small images reduce the impact, but spiky traffic always tests your scaling assumptions.

• You are running CPU-bound workloads. The default concurrency of 80 saturates CPU on image processing or ML inference services. High contention manifests as rising latency under moderate load.

• You are managing costs carefully. Minimum instances bill even at zero traffic. High max-instances allow short-lived cost spikes. See cost optimisation strategies for the broader picture of GCP spend management.

Cloud Run scaling vs Cloud Functions and traditional VMs

Cloud Functions 1st gen uses a strict one-invocation-per-instance model, which means concurrency is effectively always 1. Under high throughput, this creates many more instances than Cloud Run would for the same request volume, with correspondingly more cold start exposure. Cloud Functions 2nd gen is built on Cloud Run and shares the same concurrency model. The main difference is the programming model and trigger types. See Event-Driven Patterns with Cloud Functions for when functions are the right choice over a full Cloud Run service.

VM-based autoscaling with Managed Instance Groups scales over minutes rather than seconds, cannot scale to zero, and requires you to manage the web server concurrency yourself. VMs suit workloads that need persistent local state, GPU access, custom kernel modules, or long-running daemon processes. For stateless HTTP workloads, Cloud Run’s faster scaling and zero-idle-cost model is almost always preferable. See Choosing Between Cloud Run, GKE, and VMs for a full breakdown.