Low max-concurrency spreading Cloud Run traffic across extra warm instances
What does ZopNight detect here?
A Cloud Run service capping concurrency below 10 requests per instance forces its peak traffic across more always-warm instances than the default of 80 would need. ZopNight sizes the excess from the 30-day peak of CloudRunInstanceCount and prices it with per-second CPU and memory rates, abstaining under $5/month.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1208 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Source | cloudrun_concurrency.go |
Where it applies
Concurrency is a packing decision
Cloud Run bills each warm instance for its allocated CPU and memory, and the autoscaler
decides how many instances stay warm based on how many requests each one is allowed to
handle at once. Set containerConcurrency to 5 and a hundred concurrent requests need
twenty instances. Leave it at the platform default of 80 and the same load fits in two.
The rule fires when a service caps concurrency at a finite value below 10, the point
where the fan-out starts paying for warm capacity the workload does not need.
A setting of 0 means unlimited concurrency in Knative semantics. That is already the most instance-efficient configuration, so the rule skips it rather than treating it as the worst case.
How the footprint is measured
The evidence is the peak of CloudRunInstanceCount over 30 days, a gauge the aggregator
pins to active instances only and sums across revisions, fetched with the
monitoring.timeSeries.list permission inside roles/monitoring.viewer. The peak must
carry at least 7 days of trusted coverage; a smoothed peak from a thin series is not
enough to base a sizing call on.
An earlier version of this rule misread a per-hour request counter as a per-second rate, inflating the apparent load roughly 3600x. The current implementation only ever sizes from the instance-count gauge.
The arithmetic behind the target
Raising concurrency toward 80 packs the same measured peak onto ceil(peak × current ÷ 80) instances. Each instance eliminated stops billing its vCPU-seconds and GiB-seconds for the whole month; the saving is that warm-capacity cost, capped at the service’s total bill, and dropped entirely when it comes to less than $5 a month.
Run this before changing anything
gcloud run services describe my-service --region us-central1 \ --format="value(spec.template.spec.containerConcurrency)"Raise the value in steps and watch request latency. The ceiling only helps if a single instance genuinely can serve more parallel requests within your SLA.
When ZopNight stays silent
The rule abstains (it never emits a $0 recommendation) when concurrency is absent, unlimited, or already 10 or higher; when the instance-count metric is missing or its peak coverage is under 7 days; when the peak is zero or raising concurrency would remove no instance; when CPU or memory shape metadata cannot be parsed; when either per-second rate or the service’s cost is unknown; and when the computed saving lands under the $5 floor.