The production Cloud Run warm floor (service-level minScale=2, applied via gcloud --min) was set manually during the PR 4 host cutover and exists only as live service state — not represented anywhere in the repo. It survives CI deploys today only because the deploy never asserts a service-level min; anyone reading the repo cannot see the floor, and a future change that recreates the service from config would silently drop it.
Additionally, production max-instances is 4, but at the 50/50 LB split the service already sits pinned at that ceiling during the daytime peak (instance_count flatlines at 4.0), so the 100% Cloud Run cutover needs more headroom.
Fix: apply the service-level floor from the deploy config on every deploy (new CLOUD_RUN_SERVICE_MIN_INSTANCES env, prod 2 / staging 0, passed as --min), keep the revision-level --min-instances 0 (avoids the per-tag cost bomb), and raise production max-instances 4 → 8.
The production Cloud Run warm floor (service-level
minScale=2, applied viagcloud --min) was set manually during the PR 4 host cutover and exists only as live service state — not represented anywhere in the repo. It survives CI deploys today only because the deploy never asserts a service-level min; anyone reading the repo cannot see the floor, and a future change that recreates the service from config would silently drop it.Additionally, production
max-instancesis 4, but at the 50/50 LB split the service already sits pinned at that ceiling during the daytime peak (instance_countflatlines at 4.0), so the 100% Cloud Run cutover needs more headroom.Fix: apply the service-level floor from the deploy config on every deploy (new
CLOUD_RUN_SERVICE_MIN_INSTANCESenv, prod 2 / staging 0, passed as--min), keep the revision-level--min-instances 0(avoids the per-tag cost bomb), and raise productionmax-instances4 → 8.