Choosing Minimum Instances for Google Cloud Run Gen 2 Services with Sporadic Traffic

The short answer

There is no universal formula in the documentation, but for a genuinely sporadic service the default answer is min-instances = 0. Set it to 1 only if you have measured your cold-start latency in your target region and found it exceeds what your users can tolerate, and the added latency matters more than the roughly continuous cost of one idle instance.

What is confirmed vs. what you must measure

Confirmed behavior: with min-instances = 0, Cloud Run scales to zero after an idle period and the next request pays a cold start. With min-instances = 1, at least one instance stays warm and serves the first request without that penalty, but you are billed for its reserved CPU and memory around the clock (the exact profile depends on whether you use "CPU only allocated during request processing" or "CPU always allocated" — the latter costs noticeably more for an idle warm instance).

What you must measure yourself: the actual cold-start duration. It depends on your container image size, runtime (a Go or minimal binary typically starts much faster than a JVM app with heavy framework initialization), startup probes, and regional conditions. It is not a fixed constant, so any number you read elsewhere — including this article — should be treated as a hypothesis to verify, not a fact.

A practical decision procedure

1. Deploy with min-instances = 0. After at least 15 minutes of inactivity, send a request and record its latency. Repeat a few times at different times of day to capture variance.
2. Deploy with min-instances = 1 and measure the same request. The difference is your real cold-start penalty.
3. Decide the latency budget: if users tolerate, say, an extra 2–5 seconds on the first request after idle (typical for internal tools, webhooks, or low-traffic APIs), keep min-instances = 0. If this is a user-facing synchronous path where every request matters, consider 1.
4. Do the cost math: look up the per-second vCPU and memory pricing for your region, multiply by the seconds in a month, and compare the cost of one always-warm instance against your projected request volume. For truly sporadic traffic (a few requests per hour), the warm instance almost always costs far more than the cold starts it saves.

Reducing the penalty instead of paying to avoid it

Before reserving an instance, shrink the cold start itself: use a slim base image (distroless or alpine), remove unused dependencies, pick a fast-starting runtime if you have flexibility, and defer non-essential initialization until after the server starts listening. On Gen 2, also review your CPU allocation setting, since it changes both startup behavior and idle cost. A smaller, faster container can make min-instances = 0 acceptable even for moderately latency-sensitive services.

One caveat

Cloud Run pricing and execution-environment behavior change over time, and cold-start performance varies by region and load. Verify current pricing on the official Cloud Run pricing page and re-measure after any major image or configuration change. If your traffic later becomes steady rather than sporadic, revisit the decision — at sustained request rates, a warm instance can become the cheaper and faster option.