In Azure Portal, Advisor VM/VMSS right sizing CPU threshold can be set to 100%, but not when using ARM

Question

In Azure Portal, Advisor VM/VMSS right sizing CPU threshold can be set to 100%, but not when using ARM

Aimee Silva 40

Within Portal, the drop down option for the CPU threshold shows 100 as an option. The documentation screenshot, also shows 100 as an option. However, if we try to configure it using Bicep/ARM templates, 100 is no longer an option. The documentation seems to have removed 100 as an option and running it this week fails. This was working fine just last week.

Why was the 100 option removed from ARM/Bicep when it is still available through Portal?

Suchitra Suregaunkar 16,125 Reputation points Microsoft External Staff Moderator

2026-07-16T15:29:21.08+00:00

Hello Aimee Silva

Thank you for posting your query on Microsoft Q&A platform.

We are looking into this issue and will keep you posted updates.

Thanks,

Suchitra.
Suchitra Suregaunkar 16,125 Reputation points Microsoft External Staff Moderator

2026-07-16T16:20:21.01+00:00

Hello Aimee Silva

I hope the details shared above helped in addressing your concern.

If the suggested resolution resolved the issue, kindly consider marking as "Upvote" it. This helps other community members who may encounter a similar issue in the future.

If you’re still experiencing the problem or need further clarification, please feel free to share additional information so we can continue investigating and assist you further.

Thanks,

Suchitra.

Answer accepted by question author

Suchitra Suregaunkar 16,125 Microsoft External Staff Moderator

Hello Aimee Silva

The lowCpuThreshold property on Microsoft.Advisor/configurations has always been defined as an enumeration in the resource provider, and the only accepted values are:

5 (default), 10, 15, or 20

This is documented consistently across every current API version (stable and preview) of the resource type, and across the REST API, Bicep, and ARM template references:

ARM template / Bicep reference — Microsoft.Advisor/configurations (latest): https://learn.microsoft.com/en-us/azure/templates/microsoft.advisor/configurations — lowCpuThreshold allowed values: '5' | '10' | '15' | '20'.
REST API — Configurations - Create In Subscription (2025-01-01): https://learn.microsoft.com/en-us/rest/api/advisor/configurations/create-in-subscription "CpuThreshold … Valid values: 5 (default), 10, 15 or 20."
REST API — Configurations - List By Subscription (2025-01-01): same enum, same four values.

So 100 was never a valid value on the ARM contract, the docs page you referenced was updated recently to correct the property table so it matches what the Advisor RP actually accepts. That is why your deployment now fails validation on that value, even if a previous run appeared to succeed.

Why the Portal still shows 100:

The Azure Portal blade for Advisor's VM/VMSS right-sizing rules exposes a couple of UI options that are handled by the Portal experience itself, not by the Microsoft.Advisor/configurations ARM resource. The ARM lowCpuThreshold property specifically feeds Advisor's low CPU utilization evaluation (used to detect under-utilized VMs for shutdown/resize recommendations), which by design is bounded to a small threshold range see the algorithm details here:

Optimize VM/VMSS spend – Azure Advisor: https://learn.microsoft.com/en-us/azure/advisor/advisor-cost-recommendations

That is consistent with why the ARM enum caps at 20.

To fix this update your Bicep/ARM template to use one of the supported values. For example:

resource advisorConfig 'Microsoft.Advisor/configurations@2025-01-01' = {
 name: 'default'
 properties: {
 lowCpuThreshold: '20' // allowed: '5' (default) | '10' | '15' | '20'
 duration: '7' // allowed: '7' (default) | '14' | '21' | '30' | '60' | '90'
 exclude: false
 }
}

Equivalent REST PUT body (sample from the official reference):

{
 "properties": {
 "lowCpuThreshold": "20",
 "duration": "7",
 "exclude": false
 }
}

If you truly need a 100% threshold:

That value isn't currently expressible through the ARM/Bicep/REST contract for Microsoft.Advisor/configurations, so there's no template workaround. The best path is to open a feature request using below link:

https://feedbackportal.microsoft.com/feedback/post/

Thanks,

Suchitra.

Aimee Silva 40 Reputation points

2026-07-22T14:22:51.36+00:00

Thanks for the detailed response.

1 additional answer

Your answer

Suchitra Suregaunkar 16,125 Reputation points Microsoft External Staff Moderator

2026-07-16T15:29:21.08+00:00

Hello Aimee Silva

Thank you for posting your query on Microsoft Q&A platform.

We are looking into this issue and will keep you posted updates.

Thanks,

Suchitra.
Suchitra Suregaunkar 16,125 Reputation points Microsoft External Staff Moderator

2026-07-16T16:20:21.01+00:00

Hello Aimee Silva

I hope the details shared above helped in addressing your concern.

If the suggested resolution resolved the issue, kindly consider marking as "Upvote" it. This helps other community members who may encounter a similar issue in the future.

If you’re still experiencing the problem or need further clarification, please feel free to share additional information so we can continue investigating and assist you further.

Thanks,

Suchitra.
Aimee Silva 40 Reputation points

2026-07-22T14:22:51.36+00:00

Thanks for the detailed response.

Answer 1

The current public contract is unambiguous: lowCpuThreshold accepts only 5, 10, 15, or 20. The 2025-01-01 REST API and the ARM/Bicep resource definition use the same enumeration, so 100 is rejected by the resource provider.

The portal documentation also describes its VM/VMSS CPU setting as a filter on which recommendations are shown; it does not change how recommendations are generated. Therefore, the 100 option visible in the portal is not currently equivalent to the ARM lowCpuThreshold property.

For automation, use 20 as the maximum supported value, for example lowCpuThreshold: '20', and allow up to 24 hours for recommendations to reflect the change. If an earlier deployment appeared to accept 100, read the current configuration back instead of assuming it persisted. There is no supported ARM workaround for 100 today. If that value is required, open an Azure support or product-feedback case asking Microsoft to align the portal and resource-provider contract.