# Cloud Run Service

> Cloud Run bills per vCPU-second and per GiB-second only while instances run, unless minimum instances is above 0, which keeps warm containers billing around the clock. ZopNight watches request and instance metrics over a 42-day lookback and schedules services by zeroing min-instances, restoring the saved value on resume.

Source: https://zop.dev/integrations/gcp/cloudrun
Updated: 2026-08-19

---

Cloud Run runs containers in a fully managed serverless environment, billed for CPU and memory while handling requests. Setting minimum instances above zero keeps containers warm and billing continuously, which is the main way Cloud Run quietly accumulates cost.

## Serverless until min-instances says otherwise

Cloud Run's meters are vCPU-seconds and GiB-seconds of memory, charged while container instances are up, plus a per-request component. With request-based billing and no floor configured, a service that receives no traffic costs nothing. The minimum-instances setting changes the deal: each warm instance it pins bills for its CPU and memory allocation continuously, converting a pay-per-use service into a small always-on server. Multiply a modest floor across a dozen dev services and the "serverless" line starts resembling a VM fleet.

## Idle detection built on request metrics

ZopDev discovers Cloud Run services via Cloud Asset Inventory and tracks request and instance metrics over 42 days, which is enough history to separate a service that is genuinely used from one warm purely out of habit. A service with pinned instances and a flat request curve is the canonical finding.

## Zeroing the floor on a schedule

ZopNight schedules a Cloud Run service by setting its minimum instances to 0, saving the prior value and restoring it on resume. Nothing is deleted or made unreachable. Request-driven scaling is unaffected, so a stray overnight request still gets served after a cold start. What changes is that idle hours stop billing, which is the entire point for non-production services with pinned warm capacity.

## Cloud Run spend without traffic

The recurring leaks: minimum instances copied from a production YAML into every environment; CPU set to always-allocated for a service that only does request-time work; and revisions with generous CPU and memory limits that inflate every billed second even when traffic is real.

## Service details in the console

Google Cloud console → Cloud Run lists every service with its region and latest revision. A service's Revisions tab shows the minimum-instances value in effect, the number ZopNight zeroes on stop and restores on start.