# Azure Function Premium Plan with Low Executions > 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. Source: https://zop.dev/integrations/azure/recommendations/azure-function-premium-plan-with-low-executions Updated: 2026-08-19 --- ## 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 ```bash az monitor metrics list \ --resource $(az functionapp show -n -g --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.