Azure API Management in Production: Failure Clinic (Course #azure-apim-clinic)
For platform engineers, SREs, API operations leads, cloud architects.
By the end, you can
By the end of this course, you will be able to operate an Azure API Management estate on metrics you can defend — a per-location capacity dashboard, alert thresholds justified against tier and unit count, and a client retry contract — so that an overloaded gateway is recognised in minutes rather than misattributed to a backend.
Running case study
Kirren Mobility runs booking, telemetry and partner APIs for a fleet operating in 7 cities on a multi-region Azure API Management estate, with 140 APIs deployed against a Monday-morning peak. Its last outage was diagnosed as a backend fault for 40 minutes because the capacity dashboard looked healthy throughout, and autoscale added a unit 30 minutes after the traffic that triggered it had passed. The platform team must produce an alerting model that survives the metric's own recalculation and a documented client retry contract.
Programme every line is something you do
4 modules · 12 topics · in course-flow order
-
Module 1
It degrades, it does not throttle
Objective. Characterise the overload behaviour of an API Management instance and derive the client contract it forces on every consumer.
- Establish the documented behaviour at capacity: the instance does not throttle to prevent overload, it shows increased latency, dropped connections and timeouts
- Design the protection the platform does not give you — policy-level throttling plus a retry contract with jitter for all 140 APIs
- Separate the two signatures in an incident timeline, since gateway overload and backend failure present almost identically at the client
-
Module 2
Capacity is not traffic
Objective. Read the capacity metric for what it measures and eliminate the four common misreadings from your dashboards.
- State the limit plainly: capacity metrics are not direct measures of the number of requests being processed
- Account for non-zero readings at zero traffic, caused by platform actions, and for problems that never move the metric at all
- Remove the metrics that are structurally zero for your tier — capacity reads 0 in v2 tiers, CPU and memory read 0 in classic
-
Module 3
Thresholds that survive a recalculation
Objective. Set scaling and alerting thresholds justified against tier, unit count and the metric's own revision history.
- Apply the two published thresholds correctly: scale above 60–70% sustained, but above 40% on a single-unit instance to reserve capacity for guest OS updates
- Re-derive thresholds after a metric change — the May 2025 calculation update raised reported values without changing actual performance
- Exclude Max from alerting: it is Premium-only and documented as informational, not a basis for scaling decisions
-
Module 4
Scale before you need it
Objective. Design autoscale rules and a multi-region dashboard against the platform's real timing and location constraints.
- Plan for a scaling operation that takes around 30 minutes, so rules must anticipate the peak rather than react to it
- Split capacity by location before interpreting it, and account for only the primary location being scalable in a multi-region deployment
- Damp the rules against flapping and discard the most recent 1-minute data point, using windows of 30 minutes or longer
References & Official Documentation every claim above has a source
Module 1
- RFC 6585 — Additional HTTP Status CodesSpecification
- Advanced request throttling with Azure API ManagementMuleSoft Docs
- Capacity of an Azure API Management instanceMuleSoft Docs
Module 2
- Azure API Management v2 tiersMuleSoft Docs
- Monitor published APIs with Azure MonitorMuleSoft Docs
Module 3
- Upgrade and scale an Azure API Management instanceMuleSoft Docs
Module 4
- Autoscale an Azure API Management instanceMuleSoft Docs
- Flapping in autoscaleMuleSoft Docs