Shutting down dev and QA after hours: how much you actually save

Gonzalo Gjuka — Thu, 22 Oct 2026 12:00:00 +0000

The question always arrives the same way: "if we shut dev down at night, how much does the invoice drop?". The short answer is less than the compute math says and more than most people expect. The long answer has a formula and a list of things that keep billing with everything turned off.

The math: 108 of 168 hours

A week has 168 hours. If the team uses the environment from 8am to 8pm, Monday to Friday, the VM is in use for 60 hours (12 × 5). The other 108 are nights and weekend: five 12-hour nights plus the 48 hours of Saturday and Sunday. 108 / 168 = 64%.

For any window, with N hours off every weekday night:

share off = (48 + 5 × N) / 168

N = 8 (on 16 hours a day): 88 / 168 = 52%
N = 10: 98 / 168 = 58%
N = 12: 108 / 168 = 64%
N = 14: 118 / 168 = 70%
N = 16 (on 8 hours a day): 128 / 168 = 76%

As an example: a VM billed at USD 0.10 per hour costs USD 73 per month running all the time (730 hours). With N = 12 it stops billing 64% of those hours: USD 46.93 less per month. The savings calculator does this same math with your number of VMs, their cost and your schedule.

What does not drop when you turn the VMs off

The 64% applies to the compute of the VM, not to the invoice of the environment. A dev environment has more pieces, and several keep billing with the VMs off:

Disks. They are billed per provisioned GB, with the VM on or off. The disk of a stopped VM keeps billing in full.
Managed databases. RDS, Azure SQL or Cloud SQL have their own lifecycle: turning off the VMs that use them does not stop them. On AWS, a stopped RDS instance starts again on its own after seven days.
Load balancers and NAT gateways. They are billed per hour of existence, plus processed traffic. With no VMs behind them they still bill the hour.
Public IPs. On AWS every public IPv4 address costs USD 0.005 per hour, attached or not, so the Elastic IP of a stopped instance keeps billing. The details are in unused public IPs.
Committed capacity. A VM covered by a reservation or a usage commitment is paid for regardless: turning it off returns nothing.

One Azure detail: a VM shut down from inside the operating system still holds its hardware and bills compute. It stops billing only once it is deallocated, which is what the Stop button in the portal or az vm deallocate does.

Three lists, not a percentage

That is why the Control Cloud cost advisor does not apply a percentage to the invoice total. It keeps three lists apart, because each one carries a different certainty:

Unused: paying for nothing. Proven orphaned resources that bill, such as disks with no VM, unassociated IPs or interfaces with no owner. The saving is their full cost. Anything that could not be verified stays out.
Disks of stopped VMs. The VM bills no compute, but its disk does. If the VM is not coming back, a snapshot and deleting the disk end that charge.
Off-hours shutdown. Running VMs billed by the hour. The saving of each one is its monthly cost times the share off, (48 + 5 × N) / 168, with N chosen on the page.

Each resource appears in one list only, so no saving is counted twice. And the number at the top, the possible saving, is the exact sum of the rows below it: every amount is an inventory row, at the same rates as the rest of the page. If a figure cannot be traced back to a resource, it is not there.

A saving you cannot point to in an inventory row is a marketing estimate, not an operations number.

Before the first shutdown

The math says how much can be cut; what is left is deciding who turns off what, and keeping a record. With cron scripts spread around, that turns opaque quickly, and it is the subject of operating windows in non-prod.

The order that works: first the paying-for-nothing list, then the disks of stopped VMs, and only then the schedule. The first two cut the full cost of each resource without changing anybody's working hours; the third needs the window agreed with the team that uses the environment.

DEV Community: Gonzalo Gjuka

Shutting down dev and QA after hours: how much you actually save

The math: 108 of 168 hours

What does not drop when you turn the VMs off

Three lists, not a percentage

Before the first shutdown