Consumption API returned 429" - Azure cost management throttling
Fixes Azure Cost Management API calls failing with 429 throttling errors. Use it when a cost agent polling the Consumption or Cost Management API starts getting throttled after working fine. Key trigger: the 429 response carries a Retry-After header the caller must honor.
TL;DR
Back off and retry with the delay from the Retry-After header, then cut the call rate: cache results and stop querying per resource in a loop. The 429 means you hit the tenant-level throttle on the Cost Management API, and hammering through it only extends the block.
The error
Consumption API returned 429Fix it
Capture a full 429 response and read the Retry-After header value. Expected: a number of seconds to wait before retrying.
Add retry logic that waits the Retry-After duration, with exponential backoff and jitter on repeated 429s. Expected: retries stop compounding and start succeeding.
Reduce call volume: query once per scope per day, cache the result, and never loop the API per resource or per subscription in tight succession. Expected: request count on your side drops sharply.
Re-run the collection job. Expected: 200 responses with usage data, no 429s.
Use this when
- A cost agent that polls Azure cost APIs suddenly gets 429s
- The job loops over subscriptions or resources calling the API each iteration
- Multiple agents or dashboards hit the same tenant's cost API at once
Not for this skill when
- The error is 401 or 403 (authentication or authorization, not throttling)
- The subscription is not registered for Microsoft.CostManagement (register the provider first)
- You need fresher data than the API's refresh cycle provides (throttling fixes do not speed up the data)
Variant phrasings
- Azure Cost Management API throttling 429
- too many requests Consumption API
- Retry-After Azure cost management
- cost API rate limit exceeded Azure
Why it happens
Azure throttles Cost Management queries per tenant to protect the service. Agent loops that worked on a small estate cross the line as the estate grows, because the call count scales with subscriptions and resources while the throttle does not. Retrying immediately without waiting makes the throttle window worse.
Edge cases
- 429s can also come from ARM-level throttling if you mix resource reads with cost reads; back off both
- Forecast and price-sheet endpoints share the throttle budget, so stagger different query types
- The API data itself refreshes on its own cadence; polling faster than that wastes throttle budget for identical data
- If you need high-frequency reads, aggregate in your own store and query Azure once
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_2m25zGlmWPm9TbMDuVkPig