What happens if you don't set max-instances on Cloud Run?

The service can scale up to the project's default maximum under load. A traffic spike or a retry storm fans it out toward that ceiling and bills every instance, and it opens that many concurrent connections to your backend. Set an explicit max-instances sized from your real peak to cap both.

How do I limit Cloud Run cost?

Set --max-instances to bound how far the service scales, use request-based CPU so you pay only during requests, and keep min-instances at zero unless you need warm capacity. The single biggest guard against a surprise bill is a max-instances ceiling you chose deliberately.

No max-instances, so cost is unbounded

A Cloud Run service with no max-instances can scale to the project default ceiling under a traffic flood or retry storm, and you're billed for every instance it fans out to.

see_it · fix_it

The misconfig, then the fix

Each verdict below is the actual Cloud Run Config Auditor run on the snippet, not a description of one.

before

gcloud run deploy api \
  --image=gcr.io/my-project/api \
  --region=us-central1

Fails · auditor verdictNo max-instances set, so the service can scale to the project default ceiling (100) under load or a traffic flood. A retry storm or a scrape can fan out to the cap and bill every instance. Set an explicit max-instances you can afford, sized from your real peak.

after

gcloud run deploy api \
  --image=gcr.io/my-project/api \
  --region=us-central1 \
  --max-instances=10

Passes · auditor verdictmax-instances is bounded at 10, so a traffic flood or retry storm can't fan out into an unbounded bill. Confirm it still covers your real peak with headroom.

fix · --max-instances=10

why_it_matters

Cloud Run scales to demand, which is the feature and the risk. With no max-instances set, a spike, a scraper, or a retry storm from a broken client can fan the service out to the project's default ceiling, and each of those instances bills. The failure is a cost failure: nothing errors, the service happily serves the flood, and the surprise arrives on the invoice. It also multiplies concurrent connections to whatever database sits behind the service.

Set an explicit --max-instances sized from your real peak with headroom. It caps the bill and the connection fan-out at a number you chose rather than a default you forgot. The auditor fails a deploy with no max-instances and passes it once a bounded ceiling is set, warning only when the ceiling is set so high it isn't really a cap.

no --max-instancesscales to the default ceiling--max-instances sized from real peak

more_misconfigs

Related GCP misconfigurations

Cloud Run config

Secrets pasted into plain env vars

Read it Cloud Run config

Running as the default Compute service account

Read it

See all 7 misconfigurations.

faq

Questions & answers

What happens if you don't set max-instances on Cloud Run?: The service can scale up to the project's default maximum under load. A traffic spike or a retry storm fans it out toward that ceiling and bills every instance, and it opens that many concurrent connections to your backend. Set an explicit max-instances sized from your real peak to cap both.
How do I limit Cloud Run cost?: Set --max-instances to bound how far the service scales, use request-based CPU so you pay only during requests, and keep min-instances at zero unless you need warm capacity. The single biggest guard against a surprise bill is a max-instances ceiling you chose deliberately.

Fixing one binding is easy. Getting the whole project to least privilege is the work.

I review which principals hold primitive and escalation roles, how your workloads are scoped, secrets handling, and the Cloud Run defaults that widen the blast radius. Book a call, or leave your email.

Book a call

Prefer proof first? See how this plays out in real case studies →