When running Azure Logic Apps (Standard), Azure Function Apps, or Web Apps on shared App Service Plans, you may hit resource limits like memory full, CPU full, or connection limits reached.
In a shared environment, finding the root cause isn’t always straightforward, especially when multiple apps share the same compute resources.
This guide provides a deep dive into resource consumption for Logic Apps and Function Apps, going beyond basic Azure metrics to help you pinpoint which instance and application is actually responsible for a performance bottleneck.
Why This Matters
When several workloads run in the same App Service Plan, they compete for CPU, memory, and connections. This creates a noisy neighbour effect: one application consuming disproportionate resources can slow down or block others.
While App Service Plans can scale, scaling is mostly:
- Not instant (cold start and warm-up delays still apply)
- Not unlimited (plan size and tier constraints)
Embedding resource consumption checks into your governance process allows you to:
- Detect bottlenecks early
- Minimise impact to critical workloads
- Avoid unnecessary cost from premature scaling
Recommended governance actions:
- Review per-instance CPU and memory usage weekly
- Alert when CPU > 80% for more than 5 minutes on any single instance
- Maintain a shared resource ownership register to quickly identify the responsible application owner
Understanding the Basics: Standard Metrics in Azure
The Metrics blade in the Azure Portal shows metrics such as:
- Memory working set (% and MB)
- CPU percentage
- Connections
- Data in/out
However, these numbers are averaged across all instances in your App Service Plan, and that’s where the real challenge begins.
Why Average Metrics Can Mislead You
When an App Service Plan scales horizontally, metrics are reported as averages.
Example:
| Instance | CPU Load |
|---|---|
| Instance 1 | 40% |
| Instance 2 | 50% |
| Instance 3 | 60% |
| Average | 50% |
This seems fine, but what if a large workload arrives?
| Instance | CPU Load |
|---|---|
| Instance 1 | 10% |
| Instance 2 | 50% |
| Instance 3 | 90% |
| Average | 50% |
Here, the average still looks healthy, but Instance 3 is nearly maxed out. This can cause:
- Out-of-memory errors
- Slow response times
- Failed connections
The screenshot below shows an incident from a while back where one instance reached 96% CPU usage, while the average was 57%. This only became clear after a deeper dive into the metrics.
How to Inspect Resource Consumption Per Instance
- Go to your Application.
- Open Diagnose and Solve Problems.
- Select Availability and performance – Troubleshoot.
The steps vary slightly depending on the resource type, but the process is generally the same. Focus on identifying the application that causes the largest resource spikes or has consistently high consumption.
Analyse high CPU consumption
High CPU Analyses -> click CPU drill down:
This page allows you to see the CPU usage per application and per instance.
Analyse high memory consumption
Memory Analyses –> Observations and Solutions –> Memory Drill Down
This page allows you to see the Memory usage per application and per instance.
Or it lets you inspect the average working set memory for each application.
Design Patterns to Avoid Resource Bottlenecks
- Separate plans for critical workloads to avoid noisy neighbour risks.
- Premium plans for predictable high-load workloads, faster scaling and better isolation.
- Consumption plans for bursty workloads with unpredictable usage.
- Limit concurrency for Functions and Logic Apps to avoid memory exhaustion.
- Queue-based load levelling to smooth out spikes.
Conclusion
A spike in resource consumption does not automatically mean you should scale up or out and spend money. The smarter approach is to:
- Identify the exact instance under pressure
- Find the application causing the load
- Apply design and operational fixes before spending more on infrastructure
By combining per-instance diagnostics, KQL analysis, and good governance practices, you can keep your Logic Apps and Function Apps performant, cost-efficient, and resilient.