Most non production compute runs around the clock for no reason. A week has 168 hours, but a development or test environment is genuinely used during perhaps 50 of them, so the other two thirds is idle capacity you are paying for. Scheduling those environments to deallocate outside business hours and at weekends reclaims most of that idle time. The one rule that decides whether the saving lands is the difference between stopped and deallocated: a VM stopped from inside the guest still bills for compute, while a VM deallocated through Azure releases the compute and stops the charge. Schedule deallocation, account for the disks and addresses that keep billing when the machine is off, and a large slice of the non production bill simply disappears.
Here is where the saving comes from, how to schedule it safely, and what still costs money when a VM is off.
Where does the saving come from?
The saving is pure reclaimed idle time. If an environment is needed only during working hours, roughly nine to five on weekdays, it needs to run about 50 hours a week, not 168. Deallocating it the rest of the time removes the compute charge for those hours. The arithmetic is direct: reclaiming around 118 of 168 hours removes close to two thirds of the compute cost for that environment, before any other optimization. Across a fleet of development, test, staging, demonstration, and training environments, that is often one of the largest and least disruptive savings available, because nobody is using the capacity you are switching off.
Stopped or deallocated, and why it matters
| State | How you reach it | Compute billing |
|---|---|---|
| Running | Normal operation | Full compute charge |
| Stopped (guest) | Shut down inside the operating system | Still charged, capacity is held |
| Deallocated | Stop or deallocate through Azure | No compute charge, capacity released |
This distinction is the single most common reason a shutdown schedule fails to save money. A script that powers off the guest leaves the VM in the stopped state, still holding its compute reservation and still billing. The schedule must deallocate the VM through Azure to release the compute. Confirm the resulting state is deallocated, not merely stopped, or the bill will not move.
How do you schedule it safely?
Azure offers built in auto shutdown on individual VMs, and for fleets you can drive deallocation and start up on a schedule through Azure Automation, Functions, or a start and stop solution applied by tag. The robust pattern is to tag every non production resource with its schedule, drive deallocation and restart from those tags, and default new non production resources to a schedule so coverage does not decay as the estate grows. Add a simple override so an engineer who needs an environment outside hours can keep it up, and stagger restart times so a fleet does not all wake at once. The governance point is that the schedule must be the default and tag driven; a manual, opt in approach erodes within weeks as people forget to switch things off.
What still costs money when a VM is off?
Deallocation stops the compute charge, but it does not make the environment free. Managed disks continue to bill for the storage they occupy whether the VM is running or not, any reserved public address may keep a small charge, and some attached or dependent resources continue to cost. For most non production VMs the compute dominates, so deallocation still removes the majority of the cost, but the residual storage and address charges are worth knowing. They also point to a sharper decision: an environment that is needed only occasionally may be cheaper to decommission entirely, keeping its configuration as code to rebuild on demand, than to keep stopped and pay the standing disk cost indefinitely.
A worked example
A professional services firm ran around sixty non production VMs across development, test, and staging, all running continuously, with an earlier shutdown script that only powered off the guest so the machines stayed in the stopped state and kept billing. Replacing it with a tag driven schedule that deallocates outside business hours and at weekends, and confirming the deallocated state, cut compute on those environments by close to two thirds. A further review found a dozen environments used only a few days a quarter, which were decommissioned to code and rebuilt on demand, removing their standing disk cost as well. The combined change took a meaningful slice off the monthly bill with no impact on delivery. Figures are verified against billing data and anonymised.
Frequently asked questions
How much can scheduling non production off save?
What is the difference between stopped and deallocated on Azure?
What still costs money when an Azure VM is off?
Switch off what nobody is using
We put tag driven schedules across non production estates, confirm deallocation actually saves, and decide what to switch off versus decommission, as an independent advisory that takes zero provider commissions and answers only to you. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on a Fixed Fee or a no risk Gainshare basis. Download the cloud cost optimization playbook, read the deeper Azure cost optimization guide, and see the same move on AWS in scheduling non production environments off on AWS. For monthly buyer side analysis, subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.