Cost

Eliminate unprovisioned ExpressRoute circuits

An ExpressRoute circuit starts billing the moment its service key is issued, not when traffic flows. A circuit left in provider status 'Not provisioned' is a private connection you are paying for and not using: find every one that has sat unprovisioned for over a month and delete the ones nobody is going to light up.

12 min·10 sections·AZURE

Last reviewed 18 June 2026

Unprovisioned ExpressRoute circuits: the basics

What does a circuit you are paying for but not using actually look like?

An ExpressRoute circuit is the Azure-side half of a private connection between your network and Microsoft. Creating one is a two-party handshake: you create the circuit resource in Azure, which issues a service key, and your connectivity provider then provisions their side against that key. Until the provider finishes, the circuit sits in provider status 'Not provisioned'. The catch is that Azure bills the circuit from the moment the service key is issued, not from the moment the provider lights it up or the first packet flows. A circuit that never gets provisioned is therefore a private connection you are paying for and not using.

Azure Advisor turns this into a specific cost recommendation: 'Reduce costs by eliminating unprovisioned ExpressRoute circuits'. It flags any circuit that has been in provider status 'Not provisioned' for more than one month and recommends deleting it if you are not planning to provision it with your connectivity provider. The signal is deliberately conservative: a month is long enough that a circuit stuck unprovisioned is almost never a provisioning still in flight and almost always an abandoned plan, a cancelled migration, or a test someone forgot to tear down.

Most of this spend is drift, not intent. A circuit spun up for a datacentre migration that slipped, a proof of concept that proved the point and moved on, a provider order that fell through, a circuit recreated in a different region while the original was left behind. Each one keeps billing at its monthly port charge for as long as the resource exists in Azure. The work is to find every circuit sitting unprovisioned past the one-month mark, confirm which are genuinely waiting on a live provider order, and delete the rest to stop the meter.

In this lesson you will learn why an ExpressRoute circuit bills from the moment its service key is issued rather than from first traffic, how Azure Advisor identifies circuits stuck unprovisioned past the one-month mark, and how to confirm which are abandoned and delete them safely without disturbing the provisioning that is genuinely still in flight. The Keep learning section links the Advisor cost reference and the ExpressRoute workflow and billing documentation.

Fun fact

The meter that starts before the cable does

It surprises a lot of teams that an ExpressRoute circuit starts billing the instant Azure issues its service key, well before the connectivity provider has plugged anything in and long before a single packet crosses it. The service key exists precisely so you can hand it to your provider to provision their side, so the gap between 'circuit created and billing' and 'circuit actually carrying traffic' can be days, weeks, or, for an abandoned circuit, forever. That design is reasonable, Microsoft is holding capacity for you, but it is exactly why a circuit a provider order never completed against keeps quietly charging until somebody deletes the resource in Azure.

Finding unprovisioned circuits across a subscription

Priya runs the cloud platform at a company that finished a datacentre exit last year. Azure Advisor's Cost tab is showing the 'Reduce costs by eliminating unprovisioned ExpressRoute circuits' recommendation against two subscriptions, and the estimated monthly saving is not trivial.

Rather than act on the Advisor card blind, Priya lists the circuits directly so she can see which are still in provider status 'Not provisioned' and separate a genuinely pending provisioning from the leftovers of the migration.

List every ExpressRoute circuit with its provider and circuit status, so the unprovisioned ones stand out from the live links.

$ az network express-route list --query "[].{name:name, provider:serviceProviderProvisioningState, circuit:circuitProvisioningState, sku:sku.family}" -o table

Name Provider Circuit Sku

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

er-prod-uksouth Provisioned Enabled UnlimitedData

er-dc-migration NotProvisioned Enabled MeteredData

er-poc-westeu NotProvisioned Enabled MeteredData

# Two circuits sit in NotProvisioned. Both still bill the monthly port charge.

A circuit can be 'Enabled' on the Azure side (circuit status) while the provider side is still 'NotProvisioned'. It is the provider status that decides whether the link is actually carrying traffic, and the charge applies either way.

How Advisor decides an ExpressRoute circuit is wasted spenddeep dive

Two properties on the circuit tell the whole story. 'circuitProvisioningState' is the Azure side: it reads 'Enabled' as soon as the circuit resource exists, which is why a brand-new circuit looks 'Enabled' even though nothing is connected to it. 'serviceProviderProvisioningState' is the provider side, and it moves through 'NotProvisioned', 'Provisioning' and 'Provisioned'. A circuit only carries traffic once the provider side reaches 'Provisioned'. In the portal these appear as 'Circuit status' and 'Provider status' in the circuit's essentials.

Advisor watches the provider side. Its 'Reduce costs by eliminating unprovisioned ExpressRoute circuits' recommendation fires when a circuit has been in 'Not provisioned' for more than one month, on the reasoning that a provisioning genuinely in flight completes in days, not weeks, so a month of 'Not provisioned' means the order was abandoned or never placed. Crucially, the billing does not wait for any of this: the circuit is billed from the moment its service key is issued at creation, and that charge continues every month until the circuit is deleted in Azure, regardless of whether the provider side ever moves off 'NotProvisioned'.

The metered or unlimited choice in the SKU family, 'MeteredData' or 'UnlimitedData', changes how outbound data transfer is priced, but it does not change this: both carry a fixed monthly circuit charge that an unprovisioned circuit incurs in full while moving no data at all. That is why the safe action is deletion rather than resizing. There is no smaller SKU that makes an unused circuit worth keeping; the value of an unprovisioned circuit is zero, so the right cost is zero, which means removing the resource.

What is the impact of leaving an unprovisioned circuit in place?

The direct impact is a recurring charge for nothing. The circuit incurs its full monthly port charge for as long as the resource exists, and because it is never provisioned, it returns no connectivity, no resilience and no traffic in exchange. Unlike an oversized but used resource, there is no partial value to set against the cost; the entire charge is waste. Left alone, that charge does not lapse or self-correct, it simply repeats on every invoice until someone deletes the resource.

The second-order impact is that it hides in plain sight. An ExpressRoute circuit looks like infrastructure, so it tends to be assumed load-bearing and left untouched during cost reviews, while its provider status, the field that would reveal it is doing nothing, is rarely the thing anyone checks. The longer it sits, the more institutional memory of why it was created fades, which paradoxically makes teams more nervous about deleting it even though an unprovisioned circuit is the safest possible thing to delete.

There is no upside to leaving it. A genuinely pending circuit, one a provider is actively turning up, is the only exception, and Advisor's one-month threshold is designed to exclude exactly that case. Everything past it is recurring spend with a zero return, and the cost of inaction is simply that the charge keeps recurring, compounding into a meaningful annual figure for a resource nobody is using.

How do you remove an unprovisioned circuit safely?

Work the recommendation as a short, ordered checklist rather than a blind delete. The order matters: confirm there is no live provider order, then clear anything attached to the circuit, then delete it, so the operation cannot fail halfway or remove something genuinely pending.

1. Confirm the circuit is genuinely abandoned

For each flagged circuit, check 'serviceProviderProvisioningState' is still 'NotProvisioned' and confirm with the network team or provider that no order is in flight. Advisor's one-month threshold means a provisioning genuinely in progress is unlikely to be caught, but a quick confirmation costs nothing and rules out deleting a circuit a provider is days away from lighting up.

2. Clear anything attached before deleting

A circuit cannot be deleted while it has dependents. Remove any virtual network gateway connections, route filters, link authorisations and Global Reach configuration first. For an unprovisioned circuit these are usually empty, but list them to be sure, because a leftover authorisation or connection will block the delete with an error rather than silently.

3. Delete the circuit to stop the meter

Deleting the circuit resource in Azure is what actually stops the billing, and the charge ends in the same billing cycle. There is no separate deprovisioning step to fund for an unprovisioned circuit, because the provider side was never turned up. Capture Advisor's estimated saving against each deletion so the recurring, annualised figure lands in the savings plan.

4. Make the review recurring

Treat the Advisor cost recommendation as a standing report rather than a one-off sweep. Circuits get created for new migrations and proofs of concept all the time, so check the 'eliminate unprovisioned ExpressRoute circuits' recommendation on a regular cadence and confirm-then-delete each new arrival before it has compounded into months of wasted charge.

# 1. List circuits still on the provider side as NotProvisioned past the threshold.
az network express-route list \
  --query "[?serviceProviderProvisioningState=='NotProvisioned'].{name:name, rg:resourceGroup}" \
  -o table

# 2. For each abandoned circuit, clear link authorisations, then delete to stop billing.
RG="<resource-group>"
CIRCUIT="<circuit-name>"

for auth in $(az network express-route auth list \
    --circuit-name "$CIRCUIT" --resource-group "$RG" \
    --query "[].name" -o tsv); do
  az network express-route auth delete \
    --circuit-name "$CIRCUIT" --resource-group "$RG" --name "$auth"
done

# Deleting the circuit resource is what actually stops the monthly charge.
az network express-route delete --name "$CIRCUIT" --resource-group "$RG"
echo "$CIRCUIT deleted: monthly circuit charge stops this billing cycle."

Quick quiz

Question 1 of 5

When does an ExpressRoute circuit start incurring its monthly charge?

Keep learning

Go deeper on how ExpressRoute circuits are provisioned and billed, and on how Azure Advisor surfaces the cost recommendation.

You can now treat an unprovisioned ExpressRoute circuit as exactly what it is: a private connection you are paying for and not using. You know it bills from the moment the service key is issued, that Azure Advisor flags any circuit stuck in 'Not provisioned' past a month, and how to confirm a circuit is abandoned, clear its dependents and delete it to stop the charge in the same billing cycle. The saving recurs every month you act on it rather than leave it.

Back to the library

Unprovisioned ExpressRoute circuits: the savings view

A recurring monthly charge with zero offsetting value that you can cancel outright

This is one of the cleanest savings on the Azure bill. An unprovisioned ExpressRoute circuit carries the full monthly circuit charge for its bandwidth tier yet delivers nothing in return, because no provider is connected to it and no traffic crosses it. Deleting it removes that line from the bill permanently. There is no migration, no re-architecture and no trade-off to weigh: you are cancelling a subscription to a service that was never switched on.

Frame the saving as recurring, not one-off. Each circuit removed stops a charge that would otherwise repeat every month for as long as the resource sits there, so the annual figure is twelve times the headline number. The payback is immediate: the charge stops in the billing cycle the circuit is deleted, and there is no upfront cost to deleting it. Advisor surfaces an estimated monthly saving per circuit, which gives finance a ready figure to fold straight into the savings plan.

The only judgement call is telling a genuinely pending provisioning apart from an abandoned one. A circuit a provider is actively turning up is a few days from earning its keep and should be left alone; a circuit that has sat untouched for over a month is almost certainly dead weight. Advisor's one-month threshold does most of that filtering for you, so the finance role is to confirm there is no live provider order behind each flagged circuit and then bank the saving.

This lesson is for the finance partner who sees an Advisor cost recommendation for ExpressRoute and wants to know what it is worth, how reliable the saving is, and what the trade-off is. It covers why an unprovisioned circuit is a pure recurring charge with no offsetting value, why deleting it is risk-free, and how to turn Advisor's estimate into a banked, annualised saving.

Fun fact

The meter that starts before the cable does

How a finance partner frames the ExpressRoute saving

Priya is the finance partner sitting in on the platform team's cost review. The Advisor recommendation lands with two ExpressRoute circuits flagged across two subscriptions, each in provider status 'Not provisioned' for well over a month, and Advisor's estimated monthly saving for removing them is sizeable because ExpressRoute port charges are not small. The instinct is not to wave it through or to quibble with the engineering detail; it is to ask one question per circuit: is anyone still planning to turn this on?

The answer comes back quickly. One circuit, 'er-dc-migration', was created for last year's datacentre exit, which completed months ago, so nothing is coming. The other, 'er-poc-westeu', was a proof of concept that ended without a provider ever being engaged. Neither has a live provider order behind it, which means both are pure recurring charges with no offsetting value. Priya annualises Advisor's monthly estimate, twelve times the headline, and writes the saving into the plan as recurring rather than one-off. The finance pack reads: 'Two ExpressRoute circuits have billed the full port charge for months while carrying no traffic; deleting them stops the charge this billing cycle, the saving recurs every month thereafter, and there is no migration cost and no service to disrupt because neither was ever switched on.'

Why an unprovisioned circuit is the easiest saving to bank

The cost model here is unusually clean. The saving is the full monthly circuit charge, it recurs every month the circuit would otherwise have existed, and the cost of capturing it is zero: deleting a resource is free and instantaneous, and there is no migration, no rebuild and no downtime to fund. There is no offsetting value to lose either, because the circuit was never carrying traffic. That makes the return on the action effectively infinite, which is rare enough that it should jump to the top of the savings list.

Annualise it. Advisor surfaces a monthly estimate per circuit, and the figure that belongs in the plan is twelve times that, because the charge would have repeated all year. The finance role is to confirm there is no live provider order behind each flagged circuit, treat the rest as banked recurring savings, and resist the temptation to discount the figure for risk, because the risk of deleting an unprovisioned circuit is not a financial unknown, it is zero impact to any running service.

What finance can do about idle ExpressRoute spend

Finance cannot delete a circuit, but it owns the framing that turns an Advisor card into a banked, annualised saving and keeps the habit alive. Three levers.

1. Annualise the saving and book it as recurring

Advisor reports a monthly estimate per circuit. The number that belongs in the savings plan is twelve times that, because the charge would have repeated all year. Make the recurring nature explicit so the saving is not understated as a one-off refund: deleting one circuit removes a charge from every future invoice, not just this month's.

2. Require a one-line provider-status confirmation, not a discount for risk

The only judgement call is whether a flagged circuit has a live provider order behind it. Ask the platform team to confirm 'NotProvisioned with no order in flight' for each one, and once confirmed, treat the saving at full value. There is no execution risk to price in, because deleting an unprovisioned circuit cannot disrupt a running service, so the saving should not be hedged.

3. Put the Advisor recommendation on the recurring cost review

Circuits get created for every new migration and proof of concept, so this is not a one-time clean-up. Add the 'eliminate unprovisioned ExpressRoute circuits' recommendation to the standing cost-review agenda so each new idle circuit is caught and cancelled within a month or two rather than after it has quietly billed for a year.

Quick quiz

Question 1 of 5

Advisor estimates a monthly saving for an unprovisioned circuit. As the finance partner, how should you book it?

Keep learning

Go deeper on how ExpressRoute circuits are provisioned and billed, and on how Azure Advisor surfaces the cost recommendation.

You have finished the finance view of unprovisioned ExpressRoute circuits. You know the saving is the full recurring port charge, that it annualises to twelve times Advisor's monthly estimate, and that the cost to capture it is zero with no service to disrupt. Next time the Advisor card appears, you will confirm there is no live provider order, book the saving at full value as recurring, and put the recommendation on the standing review so new idle circuits never compound into a year of waste.

Back to the library

Unprovisioned ExpressRoute circuits: the headline

Money leaving the business every month for a private link that was never switched on

ExpressRoute is premium connectivity, and the circuit charge is one of the larger fixed line items in a networking bill. A circuit that has sat unprovisioned for over a month is that charge with nothing behind it: no provider connected, no traffic, no value. It is the cloud equivalent of paying rent on an office that was never fitted out or occupied.

The leadership question is not technical, it is housekeeping discipline: is the estate paying for connections it never finished turning on? Azure Advisor already answers it by naming each circuit that has been idle in 'Not provisioned' for over a month and estimating the monthly saving from removing it. This is a low-risk, high-certainty saving: deleting an unprovisioned circuit cannot interrupt a live service, because there is no live service on it.

Treat the recurring nature as the headline. Each circuit cleared is not a one-time refund but a charge that stops repeating, so the saving compounds across the year. The only thing standing between the business and that saving is someone confirming no provider order is genuinely in flight and then pressing delete.

A short read for the leader who needs to know what an unprovisioned ExpressRoute circuit is costing, why removing it is a housekeeping saving rather than a risk decision, and how to set the expectation that idle premium connectivity is found and cancelled rather than left to repeat on the bill.

Fun fact

The meter that starts before the cable does

What it looks like when idle premium connectivity is found and cancelled, not left to run

At a cost review the CFO asked the obvious question about a networking bill that had crept up: are we paying for anything we are not using? The honest answer at the time was that nobody was systematically checking, and ExpressRoute, being a provider-side handshake, was exactly the kind of resource that could keep billing after the project behind it had ended.

The team's response was to treat Azure Advisor's cost recommendations as a standing input rather than a curiosity. They pulled the 'eliminate unprovisioned ExpressRoute circuits' recommendation, confirmed that the two flagged circuits had no live provider order behind them, deleted them, and folded the recurring saving into the next forecast. The next time the CFO asked, the answer had changed from 'we think the bill is fine' to 'Advisor flags idle premium connectivity, we confirm and cancel it, and the saving is in the plan.' That shift, from premium charges quietly repeating to idle ones being found and stopped, is the confidence signal this recommendation delivers, and the saving recurs every month it is acted on rather than left.

Why this belongs in the savings plan, not the risk register

Most cost decisions involve a trade-off: a smaller resource is cheaper but slower, a reserved commitment saves money but locks you in. This one has no trade-off at all. An unprovisioned ExpressRoute circuit delivers nothing, so removing it costs nothing in capability and saves the full charge. It is the rare case where the financially right answer and the operationally safe answer are the same, which is exactly why it should be the quickest saving to approve.

The discipline worth setting is that premium connectivity charges get reviewed against actual provider status, not assumed to be load-bearing because they look like infrastructure. The saving from any single circuit may be modest against the whole bill, but the habit it represents, finding idle premium spend and cancelling it before it compounds across a year, is the one that keeps a cloud bill honest.

The leadership move on idle premium connectivity

The executive handle is not to approve each deletion individually; it is to set the expectation that idle premium connectivity is found and cancelled as a matter of routine, and that the saving is tracked.

1. Treat it as a fast, low-risk saving to approve

This is the rare cost action with no operational trade-off: an unprovisioned circuit delivers nothing, so removing it loses nothing and saves the full charge. Make clear that savings of this shape, high certainty, zero service impact, recurring, should move quickly rather than waiting in a queue behind harder calls.

2. Ask for the saving as an annualised, tracked number

Request the recurring saving from each deletion folded into the forecast, not reported as a one-off. The point of acting on the recommendation is that the charge stops repeating, so the value is the twelve-month figure, and it should show up in the next cost forecast as a permanent reduction.

3. Make Advisor cost recommendations a standing input

The durable win is not this one clean-up; it is the routine. Set the expectation that Azure Advisor's cost recommendations are reviewed on a cadence and acted on, so idle premium spend like an abandoned ExpressRoute circuit is found and cancelled before it compounds, rather than discovered a year later in an annual bill review.

Quick quiz

Question 1 of 5

At a cost review you ask whether the estate is paying for connectivity it does not use. What is the defensible end state for ExpressRoute?

Keep learning

Go deeper on how ExpressRoute circuits are provisioned and billed, and on how Azure Advisor surfaces the cost recommendation.

Two takeaways. An unprovisioned ExpressRoute circuit is premium connectivity you are paying for and never switched on, so removing it is a fast, zero-trade-off saving that should be approved quickly and tracked as a recurring, annualised reduction. And the durable win is the routine: make Azure Advisor's cost recommendations a standing input so idle premium spend is found and cancelled before it repeats across a year, rather than discovered late in an annual bill review.

Back to the library

Part of the learning path Kill idle Azure waste

Eliminate unprovisioned ExpressRoute circuits

Unprovisioned ExpressRoute circuits: the basics

The meter that starts before the cable does

Finding unprovisioned circuits across a subscription

How Advisor decides an ExpressRoute circuit is wasted spenddeep dive

What is the impact of leaving an unprovisioned circuit in place?

How do you remove an unprovisioned circuit safely?

1. Confirm the circuit is genuinely abandoned

2. Clear anything attached before deleting

3. Delete the circuit to stop the meter

4. Make the review recurring

Quick quiz

Keep learning

Unprovisioned ExpressRoute circuits: the savings view

The meter that starts before the cable does

How a finance partner frames the ExpressRoute saving

Why an unprovisioned circuit is the easiest saving to bank

What finance can do about idle ExpressRoute spend

1. Annualise the saving and book it as recurring

2. Require a one-line provider-status confirmation, not a discount for risk

3. Put the Advisor recommendation on the recurring cost review

Quick quiz

Keep learning

Unprovisioned ExpressRoute circuits: the headline

The meter that starts before the cable does

What it looks like when idle premium connectivity is found and cancelled, not left to run

Why this belongs in the savings plan, not the risk register

The leadership move on idle premium connectivity

1. Treat it as a fast, low-risk saving to approve

2. Ask for the saving as an annualised, tracked number

3. Make Advisor cost recommendations a standing input

Quick quiz

Keep learning

Related cost lessons