Skip to content
Costframe

Azure / Technical guide

Schedule Azure VM downtime around the workload

A development VM that only serves weekday work may not need continuous runtime. A useful schedule accounts for startup time, overnight jobs, remote users and maintenance as well as office opening hours.

Azure's Stopped state can still be allocated and billable for compute. A shutdown inside the guest is not equivalent to deallocation. The schedule's success criteria must include the intended provider power state.

Costframe editorial ·

Review the demo audit

Define the operating window with the owner

Review deployment pipelines, batch jobs, backup windows, monitoring dependencies and on-call access. A VM with little interactive activity may still host an overnight integration or a licensing service. Use the workload owner's calendar and telemetry together.

Record the time zone and daylight-saving behavior. Decide what happens on holidays, during a release, and when someone needs an exceptional session. Startup should allow enough time for the application to become ready before users arrive.

  • Exclude workloads that require continuous availability.
  • Document temporary schedule overrides and their expiry.
  • Check ordered startup for dependent services.
  • Define an owner for failed starts and failed deallocations.

Calculate only the charges the schedule can avoid

For variable compute, a planning estimate uses avoided runtime multiplied by the applicable effective hourly rate. Subtract any additional orchestration or dependent-service cost. A reservation or savings plan can change the invoice impact because the commitment continues even when this VM is not running.

Managed disks, snapshots and applicable network resources can continue billing after deallocation. Scheduling compute is not a storage-cleanup mechanism. Measure the affected compute meter separately from the entire resource group's spending.

Implement through your normal Azure change process

Azure's native shutdown controls and customer-managed automation can support scheduling. The appropriate approach depends on whether you need shutdown only, ordered restart, exceptions or policy enforcement. Choose a mechanism your team can monitor and recover.

Test a non-production instance first. Deallocation can affect startup capacity and network behavior, depending on configuration. Validate application readiness and persistent data before expanding the schedule. Keep an approved manual recovery route.

  1. Trial the window

    Observe real use and test a representative non-production service.

  2. Validate state and startup

    Check deallocation, dependencies and application health, not merely a successful scheduler invocation.

  3. Review later charges

    Compare avoided compute usage and remaining meters with the estimate.

Use Costframe for review, not schedule execution

Costframe can surface supported Azure stopped-but-billing and utilization-related findings with available evidence and limits. That can help identify a review candidate, but it does not establish the team's required operating hours.

Costframe is read-only in the customer cloud. It does not install a scheduler or automatically stop/start a VM. Your team implements the approved schedule, retains rollback context and checks the subsequent financial outcome.

References and further reading

Provider documentation explains native capabilities. Costframe availability and limitations are stated separately in this guide.

Inspect a scheduling candidate

Explore how the labelled demo distinguishes a finding, its evidence and a customer-controlled action.

Review the demo audit