SignalR units bought far above the observed peak
A SignalR instance whose peak connection quota utilisation across the window fits a smaller number of units, even after leaving the configured headroom.
Why it happens
SignalR bills per unit per day, so units bought and never needed bill exactly like units in use. The rule reads ConnectionQuotaUtilization, which Azure publishes as a percentage of the quota the current units provide, so the number of units the observed peak actually required is that percentage of what is provisioned and no per-unit capacity figure has to be assumed anywhere. The peak is used rather than the average, because sizing to an average under-provisions by construction. A headroom multiplier is applied on top and is a policy setting rather than a hidden constant: at the default the recommendation sizes for twice the highest utilisation ever seen in the window. The target is then rounded UP to a unit count Azure will accept, because units are not a free integer: Standard and Premium P1 scale across one to ten and then in tens to a hundred, while Premium P2 scales in hundreds, and rounding up means a rounding error can only leave more capacity than the calculation asked for. Reducing units within a tier is the change Microsoft documents as causing no downtime, unlike a tier change involving the free tier which moves the public IP, and this rule only ever proposes fewer units of the same tier. What it cannot see travels on every finding: a peak is history rather than a forecast, and an instance sized ahead of a launch looks identical to one that is over-provisioned.
What the agent does about it
A SignalR instance whose peak connection quota utilisation across the window fits a smaller number of units, even after leaving the configured headroom.
It will not fix this one
It reports this and takes no action. A check only earns the right to change something once the action behind it can re-read live state before it fires and knows the way back.
Related checks
SignalR service nobody connects to
A Standard or Premium SignalR instance whose highest concurrent connection count across the window was at or below the threshold, while its units bill every day.
App Service plan with no apps
A paid App Service plan hosting no applications.
App Service plan larger than its sustained demand
A plan whose sustained CPU and memory sit far below the tier it is provisioned in.