Cloud Run Service
Does ZopNight manage 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.
Rules that fire on Cloud Run Service
At a glance
| Field | Value |
|---|---|
| Scheduling notes | sets minimum instances to 0 so the service scales to zero when idle, restoring the saved value on resume |
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.