Scheduling Cloud Run Service
Can ZopNight schedule Cloud Run Service?
Cloud Run schedules change one number: minimum instances drops to 0 at night and the saved value returns in the morning. The service never stops serving, so overnight requests still work and still bill. The always-on instance floor, billed even while idle, disappears during the window.
How the stop works
| Field | Value |
|---|---|
| Behaviour | sets minimum instances to 0 so the service scales to zero when idle, restoring the saved value on resume |
Example schedules
- 0 8 * * 1-5 — Business Hours Start: Start at 8:00 AM on weekdays
- 0 18 * * 1-5 — Business Hours Stop: Stop at 6:00 PM on weekdays
- 0 22 * * * — Night Shutdown: Stop at 10:00 PM every day
- 0 6 * * 1-5 — Morning Startup: Start at 6:00 AM on weekdays
- 0 20 * * 5 — Weekend Shutdown: Stop at 8:00 PM on Friday
- 0 7 * * 1 — Weekend Startup: Start at 7:00 AM on Monday
The service stays up the entire time
Nothing here resembles a stop. The URL keeps serving at 3am; a request that arrives spins up an instance, gets handled, and bills for its duration. What the schedule removes is the minimum-instances floor, the warm instances Cloud Run holds ready around the clock when min is set above 0. Those idle instances bill continuously at the idle rate, and for a service with min-instances 2 that floor often exceeds the cost of all actual traffic combined.
Why the floor exists, and why it can sleep
Teams set minimum instances to kill cold starts during business hours. That is a legitimate latency decision. The same floor at 3am protects the latency of nobody. The schedule keeps the daytime decision and cancels the nighttime cost, restoring the saved minimum before the morning rush so the first commuter-hour request lands warm.
Cold starts move to the night shift
With the floor at 0, an overnight request pays the cold-start penalty of a second or several, depending on the container. For an internal tool that is a fine trade. For a service with a strict 24/7 latency SLO it is not, and that service was never a candidate; the schedule’s audience is the large middle whose traffic is diurnal but whose floor is constant.
The restore matters as much as the drop
Restoring at, say, 6:30 rather than at first traffic means the platform provisions the floor during quiet minutes instead of during the morning spike. The saved value is whatever the service had at the evening drop. A deploy that changed min-instances overnight is overridden by the restore, worth knowing for teams that tune scaling in their release pipeline.
Sizing the win
An idle instance-hour costs a known rate per vCPU and GB. Min 2 across a 13-hour nightly window is 26 idle instance-hours a day, times every service with a floor; across a microservice fleet, the floors quietly add up to a mid-size VM’s bill.