What the setting controls
Minimum instances ask Cloud Run to keep a baseline of service instances available when ordinary demand would otherwise fall. This can reduce waiting for initialization. It does not make an individual process permanent, prevent crashes, or guarantee capacity during every platform event. Applications still need safe startup and shutdown behavior.
There are two configuration scopes to recognize. A service-level minimum follows the service's traffic allocation. A revision-level minimum belongs to a particular immutable deployment. Current documentation recommends service-level configuration and avoiding a mixture of both. Older services can retain revision-level settings, so a cost investigation must inspect the deployed configuration rather than assume the newest default applies.
Before changing anything, identify the project, region, service owner, billing mode, and latency objective. Obtain permission to read the service and revisions. Collect an ordinary low-traffic period for comparison, and distinguish a slow first request from slow database or upstream calls.
Inspect and size the baseline
- Read the deployed service with
gcloud run services describe checkout --project=PROJECT_ID --region=REGION --format=export. Check service scaling, revision template annotations, traffic percentages, and traffic tags. Save the reviewed settings in the normal change record. This command reads configuration; it does not change capacity. - List revisions using
gcloud run revisions list --service=checkout --project=PROJECT_ID --region=REGION. Match revision names to releases and tags. Ask whether each tagged endpoint still has an active testing purpose. A revision receiving no percentage of service traffic can still receive requests through its tag. - Compare instance count, startup latency, request latency, and idle-period cost. Choose a small baseline justified by normal demand and your recovery requirement. Check the maximum instance setting and relevant resource quota before assuming the minimum can always be met.
- Apply the reviewed service-level setting through the team's deployment source. When retiring legacy revision minimums or tags, review the traffic diff first. A tag may be used by a test runner or support workflow even when it looks unused in the main traffic chart.
Illustrative scenario
A hypothetical booking service has two tagged release candidates and one production revision. The production owner expects only the production revision to stay warm. Both candidates inherited revision-level minimums from an older configuration, however, and their tags keep those minimums relevant. The correction is to confirm the candidates are no longer needed, remove their obsolete configuration through a reviewed change, and establish the intended service baseline. Increasing or decreasing production request traffic alone would not explain the whole bill.
| Observation | Evidence to collect | Likely correction |
|---|---|---|
| Idle revisions remain active | Revision minimums and tags | Retire obsolete tags or minimums |
| First request still waits | Startup and dependency timing | Fix initialization or adjust baseline |
| Minimum appears unmet | Quota, startup failures, platform events | Resolve the limiting condition |
| Cost rises after a split | Allocation and billing mode | Recalculate the intended warm capacity |
Verify the correction
Observe another comparable quiet period after the configuration takes effect. Confirm the expected traffic targets, instance floor, and cold-start behavior. Send a safe request to the ordinary service URL and to any intentionally retained tagged URL. Verify application responses as well as latency; a warm process with a broken dependency is not useful capacity. Compare cost using the relevant billing period rather than expecting billing charts to update immediately.
Operating procedure
Review tags and warm-instance settings during each release cleanup. Record why a retained tag exists and who owns it. Monitor startup failures, instance count, and request latency together. Revisit the baseline when concurrency, CPU, memory, billing mode, or traffic allocation changes. Keep a documented way to restore the previous settings if the latency objective deteriorates.
Explore Clouvenix cloud cost optimization for implementation and operational handover.