Submit feedback on
Idle or Untriggered Azure Logic Apps Generating Continuous Charges
We've received your feedback.
Thanks for reaching out!
Oops! Something went wrong while submitting the form.
Close
Idle or Untriggered Azure Logic Apps Generating Continuous Charges
Aaran Bhambra
CER:

CER-0309

Service Category
Other
Cloud Provider
Azure
Service Name
Azure Logic Apps
Inefficiency Type
Unused Resource
Explanation

Azure Logic Apps can quietly accumulate costs even when no workflows are actively executing, but the mechanism differs significantly depending on the deployment model. In the Consumption (multitenant) plan, Logic Apps with polling triggers continue to generate billable trigger executions every time the trigger checks for events — even when no events are found and no workflow runs are initiated. A polling trigger configured to check every 30 seconds produces thousands of billable executions per day, all charged at the per-execution rate, regardless of whether any useful work is performed. Webhook or push-based triggers avoid this particular waste, but retained run history and storage operations can still accrue minor costs over time.

In the Standard (single-tenant) plan, the cost driver is fundamentally different. Customers pay for reserved compute capacity — vCPU and memory — on an hourly basis, whether or not any workflows execute. An idle Standard Logic App incurs the full hosting plan charges around the clock. Disabling a Standard Logic App prevents triggers from firing but does not stop the hosting plan billing; only deletion or consolidation of the underlying plan reduces costs.

These idle Logic Apps commonly arise after application decommissioning, migration projects, or proof-of-concept work that was never cleaned up. At enterprise scale, where dozens or hundreds of Logic Apps may exist across multiple environments, the cumulative waste from untriggered workflows and unused hosting plans can become substantial — particularly when the resources are spread across teams and subscriptions with no centralized review process.

Relevant Billing Model

Azure Logic Apps uses two fundamentally different billing models depending on the deployment tier:

  • Consumption plan: Billed per execution for triggers, actions, and connector calls. Critically, polling triggers are metered and billed on every execution attempt — including when the trigger state is "Skipped" or "Failed" — meaning an idle Logic App with a polling trigger continuously generates charges even when no workflows run. Storage operations for run history and workflow state are billed separately.
  • Standard plan: Billed for reserved compute capacity (vCPU and memory) on an hourly basis, regardless of workflow activity. Built-in operations are included at no additional cost, but managed connector calls incur per-execution charges. The hosting plan charges persist as long as the resource is provisioned, even if all workflows are disabled.

In both models, integration accounts (used for B2B/EDI scenarios) are billed at a fixed rate per tier, independent of the Logic App's execution activity. Related resources such as storage accounts and API connections also continue to accrue costs until explicitly deleted.

Detection
  • Identify Logic Apps across all subscriptions and resource groups that have had no successful workflow runs over a representative period
  • Review trigger execution history to detect Logic Apps where triggers fire repeatedly but workflows are never initiated — indicating polling triggers checking for events that never arrive
  • Assess the ratio of trigger executions to actual workflow runs to identify Logic Apps with consistently high trigger activity but negligible useful execution
  • Evaluate Standard plan Logic Apps for hosting plan utilization — identify instances where reserved compute capacity is allocated but no workflows are actively running
  • Examine whether disabled Logic Apps on Standard plans are still incurring hosting charges due to the underlying compute reservation
  • Confirm with application and integration teams whether identified Logic Apps are still required for current or planned business processes
  • Review retained run history and storage consumption for Logic Apps that have been idle for an extended period
Remediation
  • For Consumption plan Logic Apps that are temporarily idle, disable the Logic App to stop trigger executions and prevent further per-execution charges — this is effective because disabling stops polling triggers from firing
  • For Standard plan Logic Apps that are no longer needed, delete the Logic App resource or consolidate workloads onto fewer hosting plans, since disabling alone does not reduce hosting plan charges
  • For Logic Apps confirmed as permanently obsolete on either plan, delete the Logic App and also clean up related resources — including integration accounts, API connections, and associated storage accounts — which continue to incur costs independently
  • Where polling triggers are necessary but workflows run infrequently, consider increasing the polling interval to reduce the volume of billable trigger executions on Consumption plans
  • Establish a periodic review process to audit Logic Apps across environments, flagging those with no recent executions or consistently low trigger-to-run ratios for team review
  • Implement tagging and ownership policies so that every Logic App has a clear owner and purpose, making it easier to identify candidates for decommissioning during regular audits
Submit Feedback