Cloud Run services capped below 10 concurrent requests per instance

Low concurrency multiplies instance count

The concurrency guide explains the setting: the maximum number of requests one instance processes at the same time, up to 1,000. Services deployed with gcloud or Terraform default to 80 times the number of vCPUs; the console default is 80. Lower the limit and Cloud Run needs more instances for the same load. Google’s cost note puts it plainly: “A higher concurrency setting lets fewer instances handle the same request volume, which can reduce costs.”

Low values are sometimes right. Google itself suggests concurrency 1 for code that cannot process parallel requests. They are also often left over from debugging or copied from a template.

Reading concurrency and instance counts yourself

gcloud run services list --region=us-central1
gcloud run services describe SERVICE --region=us-central1 --format=yaml

containerConcurrency in the revision spec is the limit. Then chart run.googleapis.com/container/instance_count filtered to state="active" in Metrics Explorer to see how many instances actually served traffic at peak.

Signals ZopNight combines

The service’s max concurrency must be set and below 10. ZopNight takes the peak active instance count from the last 30 days, and requires at least 7 days of peak data before trusting it. It also needs the service’s vCPU and memory settings and per-second rates for both.

Cases where it holds back

No finding appears when concurrency is not set as a limit, when no active instance series exists, when peak coverage is under a week, or when raising concurrency would not remove a single instance. Idle instances are excluded on purpose, because warm minimum instances are priced by the min-instance rules, and counting them here would double the saving. A result under $5 a month is dropped.

Instances a concurrency of 80 would remove

instances at target = ceil(peak active instances x current concurrency / 80)
instances saved     = peak active instances - instances at target
saving = instances saved x (vCPU x vCPU rate + GiB x memory rate) x seconds per month,
         capped at the service's cost

Raising concurrency without breaking the service

1. Check that the code is safe for parallel requests: shared globals, connection pools and per-request temp files are the usual traps.
2. Review request latency and CPU per instance; a CPU-bound single-threaded app gains little.
3. Raise the limit in steps: gcloud run services update SERVICE --region=us-central1 --concurrency=40.
4. Watch latency and error rate after each step before going higher.