# Idle Azure Function App

> Function apps on Premium or Dedicated hosting whose execution count and execution units sit below a small non-zero floor, on both average and maximum over 30 days, are flagged as idle. Savings equal the full priced plan cost; Consumption-plan apps abstain because no standing charge exists to reclaim.

Source: https://zop.dev/integrations/azure/recommendations/idle-azure-function-app
Updated: 2026-08-19

---

## Only Premium and Dedicated plans have standing cost

- resource.Metadata hosting_plan (resource_graph.go classifyFunctionAppHostingPlan, lowercase consumption/premium/dedicated). consumption and absent/unrecognised plans abstain (no standing cost to reclaim); premium/dedicated fire. On real aggregator data the dedicated arm is currently dead-but-safe: calc_azure.go's calcAzureFunctionApp prices a dedicated Function App at $0 (the cost is billed on the parent App Service Plan, covered separately by RC-222), so the rule's fCost\<=0 gate abstains rather than fabricating a run-rate.

## Reclaiming the whole plan run rate

Run-rate: the full priced Premium/Dedicated plan monthly cost (SavingsUSD = CurrentCostUSD, OptimizedCostUSD = 0). Concrete-or-abstain: no priced plan cost means no rec, never $0.

## Why stopping the app saves nothing

1. Check Azure Monitor FunctionExecutionCount/FunctionExecutionUnits over 30 days
2. If every present execution axis is below the idle floor, the function is unused
3. Delete the function app if no longer needed
4. Otherwise downgrade from Premium/Dedicated to the Consumption plan to drop the standing charge
5. Pausing/stopping the app alone does not stop the standing plan charge; only delete or downgrade reclaims the reported savings
the one-click action wired to this rule (autoremediation_allowlist.go, StepKindPauseService) dispatches to WebAppsClient.Stop only, which halts trigger dispatch but does not release the Premium/Dedicated plan's reserved instances, so it does not by itself realize SavingsUSD. Only the manual delete/downgrade remediation above reclaims the cost. The rule's Description/Remediation text states this explicitly; reconciling the wired step itself (e.g. re-keying to a delete/downgrade-capable step) is tracked as a follow-up outside function_idle.go.

## Execution counts gate, bytes corroborate

FunctionAppExecutionCount + FunctionAppExecutionUnits (Microsoft.Web/sites, 30d, gated on both Average AND Maximum below a small non-zero floor) + FunctionAppBytesSent/FunctionAppBytesReceived (corroboration only, never the sole idle gate)