Build an automated resource scheduler for non-prod by tagging each dev and test resource with a schedule, defining named on-and-off patterns with explicit time zones, and running a native scheduler or a function on a cron trigger that starts and stops resources by tag. Add an override so off-hours work is never blocked, sequence stateful resources carefully, then measure the saving. Stopping non-production compute outside working hours removes roughly 65 percent of its runtime, making this one of the largest low-risk savings in the rightsizing playbook. Note that stopped instances still bill for attached storage, so pair scheduling with idle-resource cleanup.
Last updated: June 2026
An automated resource scheduler for non-prod is automation that starts and stops development, test, and staging resources on a defined schedule, so they only run when teams are actually using them. It reads a schedule tag on each resource and applies start and stop actions on a timer, typically stopping instances overnight and across weekends. This is the Cut step of FinOps applied to its easiest target: schedule idle resources first, before committing to anything, because non-production fleets sit idle most of the week and the savings are immediate and low risk.
This article is part of our rightsizing and waste elimination cluster. For the full picture start with the complete guide to cloud rightsizing and waste elimination, the pillar this piece links up to. Scheduling removes runtime, but idle infrastructure that nobody scheduled still needs finding, covered in how to detect and remove orphaned load balancers.
How much can scheduling non-production resources save?
Running non-production resources only during business hours removes roughly 65 to 70 percent of their compute runtime and therefore most of their on-demand compute cost. A standard week has 168 hours; a business-hours-only schedule of about 50 hours leaves a resource running for under a third of the week, so the rest of the compute cost disappears. The exact figure depends on how much of your spend is non-production and how aggressive the off-hours window is, but for dev and test fleets this is consistently one of the largest, lowest-risk savings available, which is why we run it early in almost every engagement.
What is a non-production resource scheduler?
A non-production resource scheduler is automation that applies start and stop actions to dev, test, and staging resources based on a schedule, so they are not running when nobody needs them. Each resource carries a schedule tag, and a scheduling mechanism on a cron trigger reads that tag and turns the resource on in the morning and off at night. AWS publishes a reference implementation, the Instance Scheduler on AWS, and the same tag-driven pattern works with a scheduled function on any cloud.
How do I build a non-production scheduler, step by step?
Follow these six steps to build a scheduler that pays for non-production compute only during working hours.
- Tag schedulable resources. Tag every non-production instance and database with a schedule tag that names the on-and-off pattern it should follow, so the scheduler knows what to act on and what to leave alone.
- Define schedules and time zones. Create named schedules such as business-hours and weekdays-only with explicit start, stop, and time zone values, so there is no ambiguity about when a resource runs across regions.
- Choose the scheduling mechanism. Use a native option such as AWS Instance Scheduler, or a function on a cron trigger that reads the schedule tag and calls start or stop. Keep it simple and observable.
- Add an override mechanism. Give engineers a tag or self-service button to keep a resource up temporarily, so anyone working off-hours is never blocked. An override that is easy to use is what makes teams accept scheduling.
- Handle stateful and dependent resources. Sequence dependent resources and confirm databases and stateful services start and stop cleanly in the correct order, so nothing comes up broken in the morning.
- Measure savings and expand coverage. Compare the non-production bill before and after, confirm the saving is real, then extend scheduling to more resource types and environments.
Non-production running full time for part-time work?
Our cost audit tags your non-production estate, builds the scheduler with safe overrides and stateful sequencing, and reports the saving so you keep paying only for the hours teams work. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →What should not be scheduled off?
Do not schedule off production, anything serving real users, shared services others rely on around the clock, or resources in the middle of a job such as a long build or batch run. Stateful resources need careful start and stop ordering so they do not come back corrupted, and some managed services bill even when stopped or cannot be stopped at all, so confirm the billing behavior before adding them. Scheduling is for resources that are genuinely idle outside working hours, which is most of dev and test but almost none of production.
Do stopped instances still cost money?
A stopped EC2 instance stops incurring compute charges, but its attached EBS storage and any allocated elastic IP addresses keep billing. Some managed services, such as certain database tiers, continue to charge while stopped or cannot be stopped at all. So scheduling removes the compute cost but not the storage cost, which is why the full saving comes from pairing scheduling with cleanup of idle storage and databases, covered in how to find idle managed databases across AWS, Azure, and GCP. Together, scheduling and cleanup take both the runtime and the leftover storage off the bill.
The Cloud Waste Audit Framework includes the scheduling coverage worksheet and a checklist for safe stateful start and stop ordering. It is the downloadable companion to this article.
Frequently asked questions
How much can scheduling non-production resources save?
Running non-production resources only during business hours, roughly 50 hours of a 168-hour week, removes about 65 to 70 percent of their compute runtime and therefore most of their on-demand compute cost. The exact saving depends on how much of your spend is non-production and how aggressive the off-hours window is, but for dev and test fleets it is one of the largest, lowest-risk savings available.
What is a non-production resource scheduler?
A non-production resource scheduler is automation that starts and stops dev, test, and staging resources on a defined schedule so they do not run when nobody is using them. It reads a schedule tag on each resource and applies start and stop actions on a cron trigger, typically stopping instances overnight and on weekends. The goal is to pay for non-production compute only during the hours teams actually work.
What should not be scheduled off?
Do not schedule off production, anything serving real users, shared services others depend on around the clock, or resources mid-job such as a long-running build or batch process. Stateful resources need careful start and stop ordering, and some managed services bill even when stopped, so confirm the billing behavior first. Scheduling is for resources that are genuinely idle outside working hours.
Do stopped instances still cost money?
A stopped EC2 instance does not incur compute charges, but its attached EBS storage and any allocated elastic IPs still bill. Some managed services, such as certain database tiers, continue to charge while stopped or cannot be stopped at all. So scheduling removes compute cost but not storage cost, which is why pairing scheduling with cleanup of idle storage and databases captures the rest.
The short version
Build an automated resource scheduler for non-prod by tagging schedulable resources, defining named schedules with time zones, running a tag-driven scheduler on a cron trigger, adding overrides, and sequencing stateful resources. It removes roughly two thirds of non-production compute cost with little risk. When you want the scheduler built and the rest of the waste cleared too, that is exactly what our rightsizing and waste elimination service delivers.
Written by Morten Andersen and reviewed by Fredrik Filipsson, applying the See, Cut, Lock, Run method. Independent and vendor neutral.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: FinOps Foundation Framework ↗ and FinOps Rate Optimization capability ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.