Share via

Azure Container Apps scaling even without meeting the auto-scale conditions

Sean Han 25 Reputation points
2025-12-29T05:52:28.8766667+00:00

My container apps has a minimum of 2 instances with a max of 10. The scaling rule was an http condition that scaled if there were more than 15 requests. I checked my logs, but there havent been any requests for the past 7 days, yet the container app has scaled to 8 instances.

I would like help diagnosing this situation, and would like to dispute billing for this.

Azure Container Apps
Azure Container Apps

An Azure service that provides a general-purpose, serverless container platform.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Siddhesh Desai 7,160 Reputation points Microsoft External Staff Moderator
    2025-12-29T06:26:51.64+00:00

    Hi @Sean Han

    Thank you for reaching out to Microsoft Q&A

    If container apps are scaled but it is not scaling down when the http condition is not met, It might be due to misconfiguration or missing health probe. In order to overcome this, you may need to reconfigure the health probe because when a container is marked unhealthy due to missing or failed probes, it can prevent to autoscale from scaling it down, even if the workload has decreased.

    The other reason it might happen are below:

    Ingress health checks / platform probes

    Azure infrastructure generates periodic connections (health checks, readiness/liveness probes, activator traffic). These do not appear in application logs, but they do count toward HTTP concurrency, which can trigger scaling.

    Concurrent connection–based scaling (not request count)

    The HTTP scaler is based on concurrent requests, not total requests. Long‑lived or repeated platform connections can exceed the threshold (e.g., 15 concurrent requests) even when user traffic is zero.

    Multiple active revisions

    If more than one revision is active and traffic is split, concurrency can be evaluated per revision, causing scale‑out even with very low traffic.

    Additional scalers (CPU / memory / sidecars)

    If CPU or memory scaling rules exist (including indirect usage from sidecars like Dapr), they can independently trigger scale‑out even when HTTP traffic is absent.

    Min replicas configuration

    With minReplicas set to 2, the app never scales to zero. Short‑lived metric spikes can scale replicas up and they may not immediately scale back down.

    You can run below query to get the platform metric and check if there's any spike:

    
# Replicas & concurrency over last 7 days
az monitor metrics list \
  --resource <container-app-resource-id> \
  --metric Replicas,ConcurrentRequests,Requests \
  --interval PT1H --aggregation Average

# CPU/Memory signals (if a custom scaler exists)
az monitor metrics list \
  --resource <container-app-resource-id> \
  --metric CPUUsage,MemoryUsage --interval PT1H --aggregation Average

    You can also query log analytics and ContainerAppSystemEvents table to evaluate scaling decisions and CPU metrics.

    Refer: https://learn.microsoft.com/en-us/azure/container-apps/log-monitoring?tabs=bash#azure-clipowershell

    In your Container App Overview page:

    Go to Diagnose & Solve Problems and check if there's any recommendation or failure in the scaling.

    Was this answer helpful?

  2. AI answer

    2025-12-29T05:52:37.3433333+00:00

    In Azure Container Apps, scaling behavior can sometimes lead to instances being created even when the defined scaling conditions are not met. Here are a few points to consider that may help you diagnose the situation:

    1. Minimum Replica Setting: Since your container app has a minimum of 2 instances, it will always maintain at least this number of replicas, regardless of the request volume. This means that even if there are no requests, the app will not scale down below 2 instances.
    2. Scaling Rules: You mentioned that your scaling rule is based on HTTP requests exceeding 15. If there are no requests logged, ideally, the app should not scale beyond the minimum. However, if there are other metrics or conditions triggering the scaling (like CPU or memory usage), this could lead to additional instances being created.
    3. Idle Instances: If the instances are not processing requests but are still in memory, they might be billed at a lower "idle" rate. However, they still count towards your instance total.
    4. Logs and Monitoring: It’s important to check the logs thoroughly to ensure that there are indeed no requests being processed. You can use the logging features of Azure Container Apps to diagnose any unexpected behavior.
    5. Billing Dispute: If you believe that the scaling behavior is incorrect and has led to unexpected billing, you may want to contact Azure support to dispute the charges. Provide them with the logs and details of your scaling rules for further investigation.

    If you continue to experience issues, consider reviewing the scaling rules and any other metrics that might be influencing the scaling behavior.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.