Scheduling non-production workloads is the practice of automatically stopping resources outside the hours they are actually used and starting them again when they are needed. Development, test, and staging environments are the obvious targets, because they are used during working hours and sit idle the rest of the time, yet they typically run continuously by default. A resource needed roughly 50 hours a week but billed for all 168 is idle about 70 percent of the time. Stopping it outside business hours, including weekends, removes that idle cost without removing any capability, which is why scheduling is one of the highest-return, lowest-risk moves on any bill.
This article is part of our complete guide to cloud rightsizing and waste elimination, the cluster pillar it links up to. Scheduling is part of the Cut step in our See, Cut, Lock, Run method, and it is the natural follow-on once you have used how to find idle cloud resources across providers to identify what runs part-time.
A business-hours-only schedule, running roughly 50 of 168 weekly hours, removes about 70 percent of compute runtime cost on the scheduled resources. On a large non-production estate that is one of the biggest single line items you can cut.
Step 1: Identify what can be scheduled
Not everything tolerates being stopped. Production almost never does, and some non-production systems hold state or run scheduled jobs that would break if the instance disappeared. Start by separating the genuinely interactive environments, the ones people log into during the day, from the always-on ones. Dev and test instances, on-demand staging, build agents, and personal sandboxes are prime candidates. The cleanup of those sandboxes specifically is covered in how to clean up dev and test environments. Tag the schedulable resources clearly, because the schedule will act on tags, not on guesswork.
Step 2: Define schedules by team, not by resource
Setting a schedule per resource does not scale. Define a small number of named schedules, business hours in a given time zone, extended hours, weekends-off, and apply them to resources through a tag such as a schedule name. A team in one region gets one schedule; a team in another gets a different one. This keeps the system simple as the estate grows and lets a resource's owner pick the right schedule by setting a tag, rather than filing a request. It also handles the multi-region reality that business hours differ across your offices in different time zones.
Want non-production scheduled for you?
Our cloud cost audit identifies every schedulable resource across AWS, Azure, GCP and OCI, sets safe start-stop schedules by team, and measures the saving. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Step 3: Automate start and stop, with an override
Every major cloud offers a way to stop and start resources on a schedule, whether through a native instance scheduler, a scheduled function, or an automation runbook. Use the native mechanism rather than building your own, and always give users an easy override, a way to keep an instance running late when a deadline demands it, that expires automatically so the override does not become permanent. The override is what makes scheduling acceptable to engineers: it removes the fear that the platform will switch off their work mid-task. Without it, people opt out, and the saving evaporates.
| Schedule | Runs | Approx. runtime saved |
|---|---|---|
| Business hours, weekdays | ~50 hours of 168 | ~70% |
| Extended hours, weekdays | ~65 hours of 168 | ~61% |
| Weekdays, all day | ~120 hours of 168 | ~29% |
| Always on (no schedule) | 168 hours | 0% |
Step 4: Handle state, storage, and dependencies
Stopping compute does not always stop the whole bill, and it can have side effects. Attached storage usually keeps billing while the instance is stopped, so scheduling cuts the compute cost but not the disk cost; for environments used rarely, deleting and recreating from a template may beat stopping. Some resources release their IP address on stop and get a new one on start, which breaks anything hard-coded to the old address. And a stopped database that a dev tool expects to reach will throw errors until it starts. Map these dependencies before scheduling so the first Monday morning is uneventful. The broader principle of not letting cost cuts hurt reliability is in performance vs cost: finding the right balance.
The Cloud Waste Audit Framework includes the scheduling tag scheme and the savings model we use to size the opportunity before turning anything off.
Make scheduling the default, not the exception
The lasting win is making scheduled the default state for new non-production resources, so a team has to opt out of a schedule rather than opt in. Set a default schedule tag in your infrastructure-as-code modules, so anything created in a non-production account inherits a sensible start-stop window unless someone deliberately changes it. This is the Lock step applied to scheduling, and it keeps the saving from eroding as new resources appear unscheduled. Scheduling features, stop-billing behavior, and IP-retention rules differ across AWS, Azure, GCP and OCI and change. Verify current behavior in each provider's documentation before relying on it, as of May 2026.
The short version
Identify the resources that only need business hours, define a few named schedules applied by tag, automate start and stop with an expiring override, and map state and storage dependencies before you flip the switch. Then make scheduling the default for new non-production resources. When you want it set up across the whole estate at once, that is what our rightsizing and waste elimination service delivers.