Dev and test Cloud Run services that keep minimum instances warm
What does ZopNight detect here?
Cloud Run bills instances kept warm by a minimum instance setting even when they serve no requests. ZopNight flags dev, test, QA, staging and sandbox services whose `autoscaling.knative.dev/minScale` is above 0, vetoes anything that looks like production, and prices the saving as the warm vCPU and memory those minimum instances hold all month.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1209 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Threshold | min instances > 0 on a dev/test service |
| Source | ZopNight |
| Permissions used | run.services.list · run.services.get |
Where it applies
Warm instances cost money whether or not traffic arrives
Minimum instances keep containers started so the first request skips a cold start. Google’s minimum instances page is direct about the price: “Instances kept running using the minimum instances feature do incur billing costs.” With request-based billing, those instances are billed at a lower idle rate between requests; set min instances to 0 and “you are not billed when instances are idle.” With instance-based billing you pay the full rate for every instance’s whole lifetime either way.
For a production API that trade is often worth it. For a feature branch, a QA environment or a sandbox, it is usually a latency optimisation nobody asked for.
Checking min instances on your services
gcloud run services list --region=us-central1gcloud run services describe SERVICE --region=us-central1 --format=yamlIn the YAML, look for autoscaling.knative.dev/minScale on the revision template, and
run.googleapis.com/minScale on the service for a service-level minimum.
How a service is judged dev or test
Positive evidence is required: the service name contains dev, test, qa, staging, demo or
sandbox, or its env, environment, stage or tier label says so. A production-looking name
or an env=prod style label vetoes the finding first. The minimum instance count read from the
revision template must be above 0.
Services this rule does not score
Production services are out of scope; warm capacity there is a deliberate choice, and idle warm capacity on any service is judged by GCP Cloud Run Service with Idle Min Instances. ZopNight also stays silent when it cannot read the service’s vCPU and memory settings or has no per-second rate for them.
Warm capacity times the month
saving = min instances x (vCPU x per-second vCPU rate + memory GiB x per-second memory rate) x seconds in a month, capped at the service's costScaling to zero removes exactly this always-allocated component. Capacity used to serve requests is unaffected.
Letting a dev service scale to zero
- Confirm nobody relies on the service answering instantly, such as an uptime check with a tight timeout.
- Clear the minimum:
gcloud run services update SERVICE --region=us-central1 --min-instances 0. This deploys a new revision. - If a service-level minimum is set, clear it with
--min=default. - Expect the first request after a quiet period to pay a cold start.