Azure Monitor Metrics Batch API – throttling limits and scope

Hi @Ninave, Durgesh (Contractor) Thank you for your detailed questions regarding the Azure Monitor Metrics Batch API, metrics:getBatch, using API version 2023-10-01.

We understand that you would like Microsoft to confirm the request-rate limit, the scope at which throttling is enforced, whether regional endpoints or multiple service principals receive independent quotas, and whether the API exposes remaining-quota information.

Based on the currently published Microsoft documentation, the Metrics Batch API can return HTTP 529 when the Azure Monitor Metrics backend is throttling requests. Microsoft recommends implementing an exponential-backoff retry mechanism for this response. However, the public documentation does not currently specify a fixed numeric request-rate limit or define whether throttling is enforced per service principal, subscription, region, or another scope.

1. Request-rate limit Microsoft does not currently publish a fixed numeric request-rate limit for the metrics:getBatch API. Therefore, we cannot confirm values such as 360,000 calls per hour or 3,000 requests per 30 seconds as documented service limits.
2. Scope of throttling The public documentation does not define whether the Metrics Batch throttling scope is per service principal, subscription, tenant, region, subscription and region, or another backend scope.
3. Regional endpoints The API uses a regional endpoint, and resources included in one request must belong to the same subscription, Azure region, and resource type. However, the documentation does not confirm whether each regional endpoint receives an independent throttling quota.
4. Multiple service principals Microsoft documentation does not confirm that separate service principals receive independent Metrics Batch throttling quotas. We therefore do not recommend relying on multiple app registrations as a guaranteed method of increasing API capacity without further product-team confirmation.
5. Throttling responses and headers The Metrics Batch documentation specifically identifies HTTP 529 as an indication that the Metrics backend is throttling requests and recommends exponential backoff. It does not document a Metrics Batch-specific response header or metric that reports the remaining data-plane quota. The client should implement bounded exponential backoff with jitter for 529 responses. If a Retry-After header is returned, the client should honor it. The client may also defensively handle HTTP 429 as retryable, although the published Metrics Batch guidance specifically identifies HTTP 529.

Recommended mitigation:

To reduce the likelihood and impact of throttling, we recommend the following:

• Include up to 50 unique resource IDs in each request wherever possible. All resources in a batch must be in the same subscription, Azure region, and resource type.
• Implement bounded exponential backoff with jitter for HTTP 529 responses.
• Honor the Retry-After response header if the service returns one.
• Spread requests over time and avoid sending large bursts at fixed intervals, such as at the start of every minute.
• Limit concurrent requests and gradually adjust concurrency based on successful responses and observed throttling.
• Log the HTTP status code, response headers, regional endpoint, subscription ID, request timestamp, resource count, retry count, and available correlation or trace ID for further analysis.
• After implementing these mitigations, monitor whether the frequency of 529 responses decreases.

If you have further questions regarding this answer, feel free to click "Comment". If you find the answer helpful, please click "upvote" and accept it. This helps the community by allowing others with similar queries to easily find the solution.

Hello @Ninave, Durgesh (Contractor)

Your reading of the documentation is correct. The important distinction is that metrics:getBatch is an Azure Monitor Metrics data-plane API, even though the request is scoped to a subscription and uses a regional endpoint.

Microsoft currently documents that the API can return HTTP 529 when the metrics backend throttles a request, but I couldn't find a Microsoft-published numeric request-rate limit for metrics:getBatch or documentation defining the throttle as being specifically per service principal, subscription, region, or subscription+region. Microsoft recommends exponential backoff when it returns 529.

Therefore, I wouldn't assume that separate service principals receive independent quotas, or that each regional endpoint represents a guaranteed independent quota. Those implementation details don't appear in the currently documented API contract.

What Microsoft does document is:

• The endpoint is regional: <region>.metrics.monitor.azure.com.
• A batch can contain up to 50 unique resource IDs.
• Resources in a batch must belong to the same subscription, Azure region, and resource type.
• The API is intended for high-volume metric retrieval and reduces throttling risk by retrieving metrics for multiple resources in one request.

Also, I don't see a documented metrics:getBatch response header that provides a remaining-request quota comparable to some ARM throttling headers. Since this is a data-plane request, I wouldn't rely on ARM quota headers to infer remaining Metrics Batch capacity.

For an integration, I would therefore design around 529 handling rather than a presumed fixed requests-per-second value: batch up to 50 compatible resources, limit unnecessary parallelism, use exponential backoff with jitter, and log the HTTP status, response headers, region, subscription, timestamp, and any trace/correlation information returned.

If you need a contractual numeric limit or want to know whether throttling is partitioned by subscription, region, or caller identity, you'll need confirmation from the Azure Monitor engineering/support team, since the current public documentation doesn't appear to expose those values.

Please "Accept the Answer" if this information helped you. This will help us and others in the community.