Azure API Management (Developer tier): HTTP 429 Capacity Throttled

Krista Scerri 40 Reputation points
2026-08-10T10:12:07.26+00:00
  • Azure API Management, Developer tier, 1 unit, deployed in internal VNet mode, fronted by Application Gateway (WAF v2).
  • Traffic pattern: an inbound webhook that fans out to several internal API calls, all routed back through the same APIM instance.
  • Symptom Under bursts of traffic, clients intermittently receive: 
      HTTP 429
  { "statusCode": 429, "message": "Service is temporarily overloaded. Please retry later.", "activityId": "..." }
    In the APIM Requests metric these show up with Gateway Response Code = 429 and Last Error Reason = Capacity Throttled. What we've observed
    1. During throttling, the Capacity metric 1 minute Average was only moderate (~50%), while the Max briefly hit ~95%.
    2. It correlates with sudden bursts / high concurrency, not with sustained moderate throughput (gradual ramps to a higher req/s did not throttle).

Questions

  1. What exactly triggers the Capacity Throttled 429? Is it instantaneous gateway resource/CPU saturation rather than the averaged Capacity metric i.e. why can it throttle when 1 min average Capacity is ~50%?
  2. What's the recommended way to eliminate them scale out units, or move to Standard v2 / Premium (and does that materially raise the capacity throttle threshold)?
  3. Why are these platform 429s absent from the gateway diagnostic logs and visible only in the Requests metric?
Azure API Management
Azure API Management

An Azure service that provides a hybrid, multi-cloud management platform for APIs.

Answer accepted by question author
Jose Benjamin Solis Nolasco 11,621 Reputation points Volunteer Moderator
2026-08-10T12:06:49.88+00:00

Hello @Krista Scerri , I hope you are doing well,

Welcome to Microsoft Q&A.

The behavior you are seeing is consistent with capacity throttling at the APIM gateway level during short bursts of concurrency. The 1-minute Average Capacity metric does not necessarily represent the instantaneous resource pressure that caused the 429. A brief saturation event can therefore produce Capacity Throttled while the 1-minute average remains around 50%.

For your questions:

  1. What triggers the 429? Capacity Throttled indicates that the APIM gateway could not accept additional requests at that point in time. The Max Capacity metric reaching ~95% during the bursts supports this explanation. The Average metric should not be used as the sole indicator for short-lived saturation.
  2. How to eliminate the 429s? First, I would test scaling out the APIM instance and distribute the burst workload across multiple units. If the workload requires consistently higher throughput/concurrency, moving to a tier designed for larger production workloads, such as Standard v2 or Premium, can also be considered. However, there is no single documented percentage threshold that guarantees when Capacity Throttled will occur; the effective capacity depends on workload characteristics and policies.
  3. Why aren't they in gateway diagnostic logs? These 429s are generated by the APIM platform before the request reaches normal gateway processing, so it is possible to see them in the Requests metric without an equivalent gateway diagnostic-log entry. The Gateway Response Code = 429 and Last Error Reason = Capacity Throttled dimensions are therefore particularly useful for identifying this condition.

If the issue persists after scaling out, please capture the Capacity Max, request count, and 429 count over the same short time window. This will help determine whether the bottleneck is APIM gateway capacity or the burst/concurrency pattern itself.

If my answer helped you, please consider marking it as accepted. This helps others in the community find similar solutions.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Likhitha Sulake 175 Reputation points Microsoft External Staff Moderator
    2026-08-11T14:57:28.7833333+00:00

    Hello @Krista Scerri ,

    Based on the additional testing results, I would not treat the estimated “up to 500 requests/sec” figure as a strict capacity guarantee. Azure API Management throughput can vary significantly depending on workload characteristics such as concurrent connections, policy execution, request and response sizes, TLS handshakes, backend latency, and network conditions. The documented throughput figures should therefore be considered planning estimates rather than fixed service limits.

    The fact that throttling was observed at Capacity (Avg) values of 14%, 28%, and 55% suggests that the issue may be related to short-lived concurrency or processing spikes rather than sustained throughput. A relatively low average Capacity value does not necessarily mean that the gateway was not experiencing resource pressure during those burst windows.

    The current architecture also needs to be considered. The service is running on the Developer tier with a single unit, which provides limited resources and does not support scale-out. In addition, the internal VNet configuration, Application Gateway integration, and the fan-out pattern where requests are routed back through the same APIM instance can contribute additional processing and connection pressure during traffic bursts.

    Based on the current evidence, I recommend the following approach:

    Upgrade to a production tier that supports scaling, such as Standard v2, and repeat the same load tests.

    If remaining on a classic tier, increase the number of APIM units and compare the throttling behavior under the same workload.

    During testing, correlate Request Count, 429 responses, and Capacity metrics specifically around the periods when throttling occurs.

    If throttling continues after scaling, collect the corresponding metric data, timestamps, request patterns, and test results and open a support request for further platform-level investigation.

    The behavior observed so far is consistent with a workload that may be sensitive to concurrency bursts, with the single-unit Developer tier potentially contributing to the behavior. However, the available metrics are not sufficient to establish a specific request-per-second threshold at which throttling will occur. APIM capacity is workload-dependent, so there is no single fixed threshold that can be applied to all scenarios.

    Therefore, the most useful next step is to repeat the same load test on a scalable production tier. If the 429 “Capacity Throttled” events decrease or disappear after scaling, this would provide strong evidence that the current limitation is related to gateway capacity or burst handling.

    Please share the results of the testing after moving to the scalable tier, and we can review the behavior further based on the observed metrics.

    Was this answer helpful?

    0 comments

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.