Premium Function plans whose 30-day peak stays under 100 invocations an hour
What does ZopNight detect here?
Premium Function plans bill for always-ready instances around the clock. Rule RC-1314 flags a plan when peak hourly invocations stay at or below 100 across a full 30 days of Azure Monitor coverage; the recommendation is Consumption, where the first 1M executions each month are free, so the entire fixed plan cost is the saving.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1314 |
| Category | rightsizing |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | function_premium_idle.go |
Where it applies
Always-ready instances with nothing to do
An Elastic Premium plan charges for pre-warmed, always-ready instances whether or not a single function fires. That is the product: no cold starts, at a fixed hourly price. The failure mode is a function that was busy when the plan was chosen and quietly is not anymore, or a Premium plan picked “to be safe” for a webhook that fires a handful of times a day. The capacity keeps billing every hour; the workload would not notice Consumption’s cold starts.
The gates a finding must clear
Four conditions stack before rule RC-1314 says anything. The site’s hosting_plan metadata
must read premium (matched case-insensitively; absent means abstain). The
FunctionAppExecutionCount series (ZopNight’s name for Azure’s native
FunctionExecutionCount counter) must exist for the resource, and must carry at least 30
days of Azure Monitor coverage, so a plan provisioned last week can never read as idle off
two quiet days. Its per-bucket peak over that window must sit at or below 100 invocations.
And a real monthly cost for the plan must be known from billing data; without one, no
recommendation is produced. Byte counters (FunctionAppBytesSent/Received) travel along as
corroborating evidence but never gate the verdict. A plan serving few but heavy invocations
is judged on invocations, not bytes.
Pull the invocation counts yourself
az monitor metrics list \ --resource $(az functionapp show -n <app> -g <rg> --query id -o tsv) \ --metric FunctionExecutionCount --aggregation Maximum \ --interval PT1H --offset 30d \ --query "max(value[0].timeseries[0].data[].maximum)"Reading these metrics needs only the Monitoring Reader role; discovery of the plan itself is covered by Reader.
Why the saving equals the whole plan
Under this rule’s own gate (a 30-day peak below 100 invocations per hour) the workload lands comfortably inside Consumption’s free grant of 1M executions a month, which the calculator treats as ~$0. So the recommendation claims the full Premium fixed cost as the saving, with an optimized cost of zero: a measured Premium-to-Consumption delta, not a percentage guess applied to the bill.
When Premium is the right answer
Before migrating, check what Premium was actually bought for. VNet integration, unbounded execution duration, and guaranteed warm instances do not exist on Consumption; a rarely-invoked function that must reach a private database still needs the plan. Where the features are genuinely in use, dismiss the finding. The rule measures activity, and cannot see intent.