Cost

Schedule auto-shutdown for idle dev/test VMs

One capability across every non-production virtual machine: deallocate the VMs nobody uses out of hours on a daily schedule, so you stop paying for compute the moment the working day ends instead of leaving meters running through the night and the weekend.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Auto-shutdown for idle VMs: the basics

What does a dev/test VM running 24/7 actually cost you?

An Azure virtual machine bills for compute by the second for as long as it is running, whether or not anyone is using it. A dev box, a test rig, a build agent or a demo environment that a team touches during office hours still runs through every night and every weekend unless something stops it. A VM used for roughly 40 working hours a week is allocated and billed for all 168 hours in that week, so the majority of its compute cost buys nothing. Auto-shutdown is the feature that closes that gap: it stops and deallocates the VM on a daily schedule, so the meter stops out of hours.

The important word is deallocate. A VM that is merely shut down from inside the guest operating system stays allocated, and Azure keeps charging for the compute. Only when a VM reaches the 'Stopped (deallocated)' state do the compute charges stop. Azure's auto-shutdown feature deallocates the VM, which is exactly what you want: you keep paying for the OS and data disks, which is cheap, and you stop paying for the cores and memory, which is the expensive part.

Most of this waste is not a decision anybody made. It is the default behaviour of a VM that nobody told to turn off. A dev environment spun up for a sprint, a proof of concept that outlived its proof, a test fleet provisioned by a module that never set a schedule. The work is to find every non-production VM that does not need to run around the clock, put a daily deallocation schedule on it, and let the platform reclaim the out-of-hours hours that were only ever being paid for out of habit.

In this lesson you will learn how Azure bills a running VM, what 'deallocated' really means for your invoice, how to find the non-production VMs that are running around the clock, and how to put a daily auto-shutdown schedule on them safely without disrupting the few that must stay on. The lesson uses Azure Advisor to surface the candidates and the built-in auto-shutdown feature to act on them.

Fun fact

The 40-hour week on a 168-hour bill

A team using a dev VM during normal office hours touches it for roughly 40 hours a week, yet a VM left running bills for all 168 hours in that week. That means well over two thirds of the compute spend on an unmanaged dev box pays for time when nobody is logged in. Auto-shutdown started life as a feature exclusive to Azure DevTest Labs, precisely because lab VMs were the worst offenders, and Microsoft later made it available to every Resource Manager VM. The feature has not changed the maths in years: turn the machine off at night and the expensive part of the bill simply stops.

Finding always-on idle VMs across a subscription

Priya runs the platform team at a scale-up whose Azure bill has been creeping up. Azure Advisor is flagging a cost recommendation to shut down or resize underutilised virtual machines, and she suspects a layer of dev and test boxes are running through every night.

Rather than guess, she starts by listing which VMs are currently running and which already carry an auto-shutdown schedule, so she can separate the machines that are managed from the ones quietly billing around the clock.

Start by listing the VMs that are powered on but tagged or named as non-production, so you can see which idle machines are still running.

$ az vm list -d --query "[?powerState=='VM running'].{name:name, group:resourceGroup, size:hardwareProfile.vmSize}" -o table

Name Group Size

---------------- ----------- ---------------

dev-api-box rg-dev Standard_D4s_v5

test-runner-01 rg-test Standard_D2s_v5

prod-web-01 rg-prod Standard_D4s_v5

# dev-api-box and test-runner-01 are non-prod and running 24/7. Schedule them off.

A running non-production VM with no shutdown schedule is the highest-value target: it bills for nights and weekends nobody uses. Schedule these first, and leave prod alone.

How auto-shutdown actually stops the billdeep dive

Azure's auto-shutdown feature is implemented as a schedule resource attached to the VM, of type 'Microsoft.DevTestLab/schedules' with a task type of 'ComputeVmShutdownTask'. At the scheduled time it does not just power the guest down; it deallocates the VM, moving it to the 'Stopped (deallocated)' state. This distinction is the whole point. A VM stopped from inside the operating system, or sitting in the plain 'Stopped' state, is still allocated and still billed for compute. Only 'Stopped (deallocated)' releases the underlying cores and memory and stops the compute charge. You continue to pay for the OS and data disks, which is the small part of the bill, while the expensive compute meter is off.

The schedule has a daily recurrence time and a time zone. A subtle but important detail: when you set the schedule with the 'az vm auto-shutdown' CLI command, the '--time' value is interpreted in UTC, whereas the portal lets you pick a named time zone. If you set '1800' on the CLI expecting local 6pm and your team is several hours off UTC, the VM will shut down at the wrong time, so either convert to UTC for the CLI or set the time zone explicitly in the underlying schedule resource.

Auto-shutdown stops machines; it does not start them. Azure has no built-in auto-start paired with the shutdown schedule, so if a team needs their dev boxes powered on for the start of the working day, that is a separate job, typically an Azure Automation runbook, a Logic App or a Function on a morning trigger. For most dev/test cases the developer simply starts the VM when they sit down, which takes a minute or two, and that manual start is part of why auto-shutdown is so low-risk: nothing comes back on by surprise, and nobody pays for a machine that was started automatically and then left idle.

What is the impact of leaving idle VMs running?

The direct impact is recurring waste. A non-production VM with no shutdown schedule bills for compute 24 hours a day, every day, and the hours outside the working week, the nights and the weekends, buy nothing. Across a fleet of dev, test, build and demo machines this is one of the largest avoidable line items in a typical Azure bill, and because it recurs every month, the cost of leaving it untouched compounds.

The second-order impact is drift you cannot see. Always-on VMs make it harder to spot the ones that are genuinely abandoned, because a stale machine running quietly looks the same on the bill as one in daily use. Putting schedules on the estate forces the question of whether each VM is needed at all, and the deallocation event itself becomes a cheap signal: a VM nobody ever bothers to start back up is a strong candidate for deletion.

Azure Advisor makes this concrete. Its cost recommendation to shut down or resize underutilised virtual machines identifies low-utilisation VMs, typically those with CPU and outbound network usage below a low threshold over a lookback window, and attaches an estimated saving. That estimate is the finance-visible version of the same waste: it is the money currently spent on compute that the workload is not using, and auto-shutdown is the most direct way to act on it without re-architecting anything.

How do you schedule idle VMs off safely?

Work the estate as one loop rather than scheduling machines ad hoc. The order matters: confirm which VMs legitimately need to run after hours before you start scheduling, so you do not deallocate something mid-job.

1. Inventory the non-production VMs that run continuously

List the running VMs that are dev, test, build or demo, by tag, resource group or naming convention, and note which already carry an auto-shutdown schedule. Cross-reference Azure Advisor's cost recommendation to shut down or resize underutilised VMs, which surfaces the low-utilisation machines and an estimated saving. Treat this inventory as the source of truth.

2. Separate the machines that must stay on

Most non-production VMs do not need to run out of hours. The exceptions are real but few: a build agent running nightly jobs, a shared environment used across time zones, a long-running test. For each, decide whether it genuinely needs evening or weekend hours, and record it as a named exception with a later shutdown time rather than no schedule at all.

3. Set a daily deallocation schedule, highest spend first

Put a daily auto-shutdown time on each remaining VM, prioritising the largest VM sizes because they waste the most per idle hour. Remember the CLI '--time' is UTC: convert your local cut-off time accordingly, or set the time zone explicitly. Enable the pre-shutdown notification so anyone working late gets a warning and can delay it. The change takes effect immediately and the VM deallocates at the next scheduled time.

4. Make a schedule the default for new VMs

A one-off sweep saves money once; a default keeps it saved. Bake the auto-shutdown schedule into the Bicep or template that provisions dev/test VMs so every new machine is born with one, and use Azure Policy to audit for VMs in non-production scopes that lack a schedule. That turns auto-shutdown from a thing someone remembered into the standing behaviour of the estate.

# Schedule a single dev/test VM to deallocate every evening.
# NOTE: --time is UTC and uses hhmm. 1800 UTC, not local 6pm.
az vm auto-shutdown \
  --resource-group rg-dev \
  --name dev-api-box \
  --time 1800 \
  --email "[email protected]"

# Sweep every running VM in a non-production resource group.
for id in $(az vm list -g rg-dev --query "[].id" -o tsv); do
  az vm auto-shutdown --ids "$id" --time 1800
done

# Make it the default in IaC: attach a shutdown schedule in Bicep so
# every new dev/test VM is born deallocating out of hours.
# --- shutdown.bicep ---
# param vmName string
# param vmId string
# resource shutdown 'Microsoft.DevTestLab/schedules@2018-09-15' = {
#   name: 'shutdown-computevm-${vmName}'
#   location: resourceGroup().location
#   properties: {
#     status: 'Enabled'
#     taskType: 'ComputeVmShutdownTask'
#     dailyRecurrence: { time: '1800' }
#     timeZoneId: 'GMT Standard Time'
#     notificationSettings: {
#       status: 'Enabled'
#       timeInMinutes: 30
#       emailRecipient: '[email protected]'
#     }
#     targetResourceId: vmId
#   }
# }

Quick quiz

Question 1 of 5

Why does Azure's auto-shutdown feature reduce the bill, when shutting a VM down from inside the guest OS does not?

Keep learning

Go deeper on how Azure bills a VM, how to schedule deallocation, and how to find the underutilised machines worth scheduling.

You can now treat idle non-production compute as one capability rather than a per-VM afterthought: inventory the machines running around the clock, separate the few that legitimately need after-hours time, put a daily deallocation schedule on the rest highest-spend first, and bake the schedule into your templates so new VMs inherit it. The result is a non-production estate that turns itself off out of hours and stops paying for time nobody uses.

Back to the library

Auto-shutdown for idle VMs: the savings view

A near-zero-effort change that can remove most of the compute cost of a dev/test estate

Auto-shutdown is one of the highest-return, lowest-risk cost levers in Azure because the saving is structural, not a one-off. A VM scheduled off outside a notional working week of roughly 40 hours spends about 128 of its 168 weekly hours deallocated, so for those hours its compute charge falls to zero. The disks keep billing, but disk is a small fraction of a running VM's cost, so the compute saving on a fleet of dev/test machines is large and recurring month after month.

Frame this as recovered spend rather than a project with a budget. The change itself costs nothing in Azure terms: a schedule is free, and the engineering effort is minutes per VM or a single policy across the estate. There is no licence to buy and no new service to run. The only thing standing between the current bill and the reduced one is deciding which VMs may sleep and setting the schedule.

The payback is immediate and the downside is bounded. For a genuine non-production VM, deallocating it out of hours costs nothing in lost work because nobody is using it then; the worst case is a developer who needs it after hours and starts it again in a couple of minutes. That asymmetry, a large recurring saving against a near-zero inconvenience, is what makes auto-shutdown the first cost control most teams should reach for.

This lesson is for the finance partner who sees a steady monthly compute bill for dev/test resources and wants to know how much of it is buying idle, out-of-hours running time. It covers why the saving is recurring rather than one-off, why the change costs nothing to make, and how to turn a fleet of always-on VMs into a scheduled estate with a clear, bounded set of exceptions.

Fun fact

The 40-hour week on a 168-hour bill

How a finance partner frames the auto-shutdown decision

Priya is the finance partner reviewing the monthly Azure bill with the platform team. Azure Advisor's cost recommendation to shut down or resize underutilised VMs lands with an estimated annual saving attached. The instinct is not to wave the number through as a target; it is to understand it. The saving is structural: a dev box used in office hours is allocated for all 168 hours of the week, so scheduling it off outside a roughly 40-hour working week stops the compute meter for about 128 of those hours, every week, with no licence to buy and no new service to run.

Priya asks the team to map each candidate VM to what it actually does. Two are developer boxes used only in the day, one is a build agent that runs nightly jobs and genuinely needs evening hours, and the rest are stale test machines nobody has logged into in weeks. The list is reframed as recovered spend: the developer boxes get a daily deallocation schedule that saves their out-of-hours compute at zero cost to make the change, the build agent is documented as a named exception with a later shutdown time, and the stale machines are flagged for deletion rather than scheduling. The finance pack reads: 'Most of this compute bill is buying nights and weekends nobody works; a free schedule recovers it, and the only judgement calls are the handful of VMs that legitimately run after hours.'

Why always-on dev/test belongs on the cost review

The cost model here is unusually clean. For a genuine non-production VM, the out-of-hours compute spend is pure waste, and removing it costs nothing to do and loses nothing of value, because nobody is using the machine when it is asleep. There is no licence, no migration and no new service to run; a schedule is free. The saving is the recurring compute charge for every hour the VM no longer runs, repeated every month.

Azure Advisor's cost recommendation gives finance a defensible number to work with: an estimated saving for shutting down or resizing the underutilised VMs it identifies. Treat that figure as the opening position, refine it by confirming which VMs are truly non-production and which legitimately run after hours, and then track the realised saving on the bill. The finance role is to make sure the recovered spend is visible and that always-on non-production compute is a question asked at every cost review, not a default nobody revisits.

What finance can do about the always-on gap

Finance cannot set a schedule on a VM, but it owns the framing that turns Azure Advisor's estimate into a tracked, recurring saving with a clearly bounded set of exceptions. Three levers.

1. Treat the saving as recovered spend, not a one-off

Make explicit that auto-shutdown removes a recurring charge, not a single bill item. A VM scheduled off out of hours saves its compute cost every week for as long as the schedule stands. Track the realised reduction on the monthly bill against Azure Advisor's estimate, so the saving is owned and visible rather than quietly absorbed and forgotten.

2. Make always-on non-production a question, not a default

The reason idle VMs run around the clock is that nobody is asked why. Put 'which non-production VMs run continuously, and why?' on the regular cost review. The metric that belongs there is the count of non-production VMs without a shutdown schedule, weighted by VM size, because a large always-on VM wastes far more per idle hour than a small one.

3. Require a documented reason for any machine left running

Any non-production VM left running out of hours should carry a recorded, finance-visible reason: the nightly build agent, the cross-time-zone shared environment. The distinction between 'this runs late on purpose and we know what it costs' and 'nobody ever set a schedule' is exactly what keeps the estate from drifting back to always-on once the first sweep is done.

Quick quiz

Question 1 of 5

Azure Advisor estimates an annual saving for shutting down or resizing underutilised VMs. As the finance partner, how should you treat that figure?

Keep learning

Go deeper on how Azure bills a VM, how to schedule deallocation, and how to find the underutilised machines worth scheduling.

You have finished the finance view of scheduling idle VMs off. You know the saving is recurring rather than one-off: a free schedule removes the compute cost of every out-of-hours hour, every week, with no licence and no new service to run. Next time the dev/test compute line looks high, you will reach for Azure Advisor's estimate as a starting point, confirm which VMs are truly non-production, ring-fence the legitimate after-hours machines as documented exceptions, and track the recovered spend on the bill.

Back to the library

Auto-shutdown for idle VMs: the headline

Whether the non-production estate is paying for compute it does not use

Most organisations run a layer of non-production compute, dev boxes, test rigs, build agents and demo environments, that is only needed during the working day. Left alone, every one of those machines bills 24 hours a day, seven days a week, so the estate is paying for nights and weekends nobody works. Auto-shutdown is the simple discipline that stops it.

The leadership question is not 'can we afford these environments?' It is 'are we paying for them around the clock when we only use them in office hours?' The defensible end state is that every non-production VM has a daily deallocation schedule by default, the few that genuinely need to run continuously are named exceptions, and the saving shows up on the bill rather than in a slide.

This is purely an upside decision. There is no security trade-off and no meaningful operational risk for non-production workloads. It is a question of whether the platform turns idle machines off automatically, or whether the bill keeps paying for compute that no one is using because nobody set a schedule.

A short read for the leader who wants to know whether the non-production estate is paying for nights and weekends it does not use, why scheduling idle VMs off is an upside-only decision rather than a budget cut with a cost, and what a defensible default looks like across the estate.

Fun fact

The 40-hour week on a 168-hour bill

What it looks like when idle compute is turned off by default, not by hope

After the monthly cloud bill grew faster than headcount for two quarters running, the CFO asked the obvious question at the review: what are we actually paying for? The honest answer was that a layer of dev and test VMs ran around the clock because no one had told them to stop, and whether any given machine was scheduled off depended on whether its owner happened to have set it up.

The team's response was to stop treating auto-shutdown as an optional per-VM nicety and start treating it as the default for non-production. They listed every running non-production VM, put a daily deallocation schedule on each one, documented the few that legitimately run after hours as named exceptions, and then set the expectation that any new dev or test VM carries a schedule from creation. The next bill told the story: the compute line for non-production fell and stayed down, because the platform now turns idle machines off automatically. That shift, from hoping each owner remembers to switch their box off to making the estate sleep by default, is the recurring saving this capability delivers, and the change itself cost nothing to make.

Why this is the easiest saving to approve

Nearly every cloud bill that grows faster than usage has a layer of compute running when nobody needs it. Idle non-production VMs are the clearest example: they bill around the clock for work that happens in office hours. Scheduling them off is the rare cost control with a large recurring saving, no security trade-off and no meaningful operational risk for the workloads involved.

The asymmetry is what makes this an easy call. The saving recurs every month and the cost of acting is essentially nil, while the only downside is that a developer occasionally starts a machine back up in a couple of minutes. This is the class of decision leadership should approve fastest: a structural reduction in spend that needs a schedule, not a budget.

The leadership move on idle compute

The executive handle is not to approve each schedule individually; it is to require that auto-shutdown is the default for non-production and that the few machines which run after hours are named, owned exceptions.

1. Set a date for a scheduled-by-default estate

Ask for a date by which every non-production VM either carries a daily deallocation schedule or is a documented exception, and by which new dev/test VMs inherit a schedule from their template. A default that new machines are born with is the difference between saving money once and keeping it saved as the estate grows.

2. Ask for the saving on the bill, not in a slide

The proof that this is working is not Azure Advisor's projected number; it is the actual non-production compute line on the bill falling and staying down. Ask for the realised saving tracked month over month, so the recovered spend is demonstrated rather than asserted.

3. Treat the always-on machines as named, owned exceptions

A handful of non-production VMs legitimately run after hours, and that is fine. The leadership requirement is that each is a deliberate, documented decision with an owner and a reason, not a machine nobody scheduled. The goal is not zero running VMs out of hours; it is zero unintended ones.

Quick quiz

Question 1 of 5

At a cost review you ask whether the non-production estate is paying for nights and weekends. What end state should you be looking for as the defensible answer?

Keep learning

Go deeper on how Azure bills a VM, how to schedule deallocation, and how to find the underutilised machines worth scheduling.

Two takeaways. Scheduling idle non-production VMs off is the rare cost control where the saving is large and recurring while the cost of acting is essentially nil, so it is the trade you should approve fastest. And the defensible end state is not 'we switched a few machines off last month'; it is auto-shutdown as the default for every non-production VM, inherited by new machines from their templates, with the handful that run after hours named, owned and documented.

Back to the library

Part of the learning path Kill idle Azure waste

Schedule auto-shutdown for idle dev/test VMs

Auto-shutdown for idle VMs: the basics

The 40-hour week on a 168-hour bill

Finding always-on idle VMs across a subscription

How auto-shutdown actually stops the billdeep dive

What is the impact of leaving idle VMs running?

How do you schedule idle VMs off safely?

1. Inventory the non-production VMs that run continuously

2. Separate the machines that must stay on

3. Set a daily deallocation schedule, highest spend first

4. Make a schedule the default for new VMs

Quick quiz

Keep learning

Auto-shutdown for idle VMs: the savings view

The 40-hour week on a 168-hour bill

How a finance partner frames the auto-shutdown decision

Why always-on dev/test belongs on the cost review

What finance can do about the always-on gap

1. Treat the saving as recovered spend, not a one-off

2. Make always-on non-production a question, not a default

3. Require a documented reason for any machine left running

Quick quiz

Keep learning

Auto-shutdown for idle VMs: the headline

The 40-hour week on a 168-hour bill

What it looks like when idle compute is turned off by default, not by hope

Why this is the easiest saving to approve

The leadership move on idle compute

1. Set a date for a scheduled-by-default estate

2. Ask for the saving on the bill, not in a slide

3. Treat the always-on machines as named, owned exceptions

Quick quiz

Keep learning

Related cost lessons