The short answer
Development, test and staging environments typically run continuously while their users work about forty hours a week, leaving them idle around three-quarters of the time. Scheduling them to stop outside working hours removes most of that cost with no production risk, provided people can start an environment on demand when they need it.
Key takeaways
- Around 128 of 168 weekly hours are idle in a typical non-prod environment
- A self-service start button removes the only real objection
- Databases usually need stopping too, not just compute
- Default-off with opt-in beats default-on with policing
Part of our guide to FinOps: how to actually reduce a cloud bill.
A development environment used by a team working roughly nine to six, Monday to Friday, is genuinely needed for about forty hours a week. It runs for one hundred and sixty-eight. The remaining one hundred and twenty-eight hours are paid for and idle.
No performance risk, no architectural change, no production impact. It is the highest-return change available in cloud cost work, and it is skipped constantly because it feels too simple to be worth a project.
What to include
Compute is the obvious part, but stopping only the application servers leaves most of the cost running:
- Databases. Managed database instances often cost more than the application tier. Both AWS RDS and Azure SQL support stopping instances.
- Managed node groups. Kubernetes clusters in non-production can scale to zero nodes outside hours.
- NAT gateways and load balancers. Charged hourly regardless of traffic.
Storage generally stays — you want the data when the environment restarts — but snapshots and old volumes deserve their own lifecycle policy.
How to implement it
Tag resources with a schedule, then run automation that acts on the tag. On AWS, EventBridge rules invoking Lambda, or the AWS Instance Scheduler solution. On Azure, Automation runbooks or start/stop VM solutions. In Kubernetes, a scheduled job scaling node groups.
Keep the schedule in a tag rather than in code, so changing an environment's hours does not require a deployment.
Time zones matter for distributed teams. A schedule that suits one office strands another. Either set the window to cover the union of working hours, or let each environment carry its own.
Answer the objection properly
The objection is always the same: someone will need it outside hours. That is true, and it does not require leaving everything running.
Give people a self-service start — a button in a chat channel, a small internal page, a pipeline job. Starting an environment takes a few minutes and the person doing it knows they need it. The environment then returns to the schedule the next night unless explicitly extended.
This inverts the default. Currently, everything runs unless someone takes the risk of switching it off. Afterwards, things run when someone needs them.
What to leave alone
Do not schedule anything production traffic depends on, anything running scheduled batch work overnight, or environments used by clients or auditors on unpredictable timetables. Check for overnight jobs before applying a schedule — a nightly data refresh that silently stops running is exactly the kind of failure that gets a cost programme cancelled.
Start with the environments where the owner is clear and the risk is lowest, prove it for a fortnight, then extend.
