GetExpressRoutePeeringRouteTable throttled with subscription read quota nearly full

Peter Stieber 70 Reputation points
2026-08-10T10:05:24.1933333+00:00

We're seeing consistent throttling errors on the ExpressRoute ListRoutesTable / GetExpressRoutePeeringRouteTable operation, and the details don't match Azure's documented throttling behavior. Looking for clarification on what limit is actually being hit, since it doesn't appear to be covered in the public docs.

Request being made:

POST https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.Network/expressRouteCircuits/{circuitName}/peerings/{peeringName}/routeTables/{devicePath}?api-version=2024-05-01

Error returned:

**Error returned:**

HTTP Status: 500 Internal Server Error

We've seen this consistently across multiple different subscriptions, always for this same operation. Things we've checked, that don't add up:

  • The reported throttling window (16,332,284 seconds ≈ 189 days) doesn't match any documented Azure throttling window. The documented ARM/Microsoft.Network throttling resets every few seconds (token bucket) or every 5 minutes (Microsoft.Network` RP-level limits). A ~189-day window with "0 requests" allowed doesn't correspond to anything we can find documented — it looks like it could be a broken or stuck counter rather than an intentional limit.
  • The documented subscription read quota is not exhausted when this happens. Checking the response headers on the same failing requests:
   x-ms-ratelimit-remaining-subscription-reads: 249   (of 250)
   x-ms-ratelimit-remaining-subscription-global-reads: 3749 (of 3750)

These are essentially full at the exact moment the request is throttled — which rules out the standard, documented subscription-level ARM rate limit as the cause. Whatever is throttling this call is a separate, undocumented limit.

  • A very similar, adjacent operation is not throttled. We also call GetExpressRouteCircuitArpTable for the exact same circuits/peerings, with the same request volume and pattern (parallel requests per circuit/peering/primary-secondary). That operation works fine — only GetExpressRoutePeeringRouteTable is affected. This suggests a limit specific to this one operation, not a general subscription-wide throttling issue.
  • The response is HTTP 500, not 429. Per Azure's own documented behavior, throttling should return a proper 429 Too Many Requests status with a Retry-After header. Instead we get a 500 Internal Server Error, with the 429 message embedded inside the error body text. This looks like the throttle is happening in a backend service behind the main ARM front door (the response includes an internal gateway hostname/IP, not a clean management.azure.com rejection), and that backend isn't surfacing the throttle correctly.

What we're trying to find out:

  • Is there a documented (or undocumented) per-operation or per-circuit throttling limit specifically for GetExpressRoutePeeringRouteTable / ListRoutesTable? We can't find one published anywhere.
  • Is this limit scoped per-circuit, per-subscription, or something else?
  • Why does the throttle return as HTTP 500 instead of a proper 429?
  • Is the "0 requests per 16,332,284 seconds" figure expected, or does it indicate a stuck/misconfigured counter on the backend for this operation?

Any pointers appreciated — especially if this is a known issue with this operation.

Azure ExpressRoute
Azure ExpressRoute

An Azure service that provides private connections between Azure datacenters and infrastructure, either on premises or in a colocation environment.

0 comments

3 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Allan Solomon Mejia 8,840 Reputation points
    2026-08-11T18:56:09.6366667+00:00

    Hello @Peter Stieber

    Based on the details you've provided, I agree that this does not look like the documented ARM subscription-level throttling limit.

    Microsoft documents the current ARM read limit as a token bucket of 250 subscription reads with a refill rate of 25 requests/sec, while the Microsoft.Network resource provider has a separate general limit of 10,000 read operations per 5 minutes. When those documented limits are reached, Azure normally returns HTTP 429 (Too Many Requests) together with a Retry-After value.

    In your case, the remaining subscription-read headers are effectively full when the failure occurs:

    x-ms-ratelimit-remaining-subscription-reads: 249

    x-ms-ratelimit-remaining-subscription-global-reads: 3749

    That strongly suggests the request is getting through ARM and is being throttled further downstream, likely within the Microsoft.Network/ExpressRoute backend handling ListRoutesTable, rather than by the standard ARM subscription quota. The fact that the adjacent ARP-table operation continues to succeed under the same request pattern supports that conclusion.

    The other unusual part is the HTTP 500 containing a throttling/429-style message. According to the documented throttling behavior, a genuine ARM or resource-provider throttle should normally surface as 429. Microsoft does note that resource providers can apply their own throttling independently of ARM, but I couldn't find a published per-operation or per-circuit limit specifically for GetExpressRoutePeeringRouteTable / ListRoutesTable.

    The reported "0 requests per 16,332,284 seconds" window is also not consistent with any of the documented ARM or Microsoft.Network throttling windows. I would therefore treat that value as potentially coming from an internal backend quota/counter rather than an intentional public API limit.

    As a mitigation, I would still serialize or reduce parallel ListRoutesTable calls and implement exponential backoff, since that may reduce pressure on the backend. However, given that you've reproduced this across multiple subscriptions and only this specific operation is affected, I don't think client-side throttling alone explains the behavior.

    At this point, this would be appropriate for the Azure ExpressRoute/Microsoft.Network engineering team to review. If possible, please capture and provide through a Microsoft support case or moderator private message:

    Subscription and ExpressRoute circuit IDs

    • Azure region
    • UTC timestamp of a failed request
    • x-ms-request-id / correlation ID
    • Complete response headers and error body
    • API version (2024-05-01)
    • Approximate request concurrency/rate
    • Confirmation that GetExpressRouteCircuitArpTable succeeds at the same time

    Those identifiers should allow the backend team to determine which throttle or internal counter is actually generating the response.

    Microsoft Moderator Suchitra Suregaunkar, Please assist Peter on this? Thank you.

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

    Was this answer helpful?

    1 person found this answer helpful.
    0 comments
  2. Peter Stieber 70 Reputation points
    2026-08-13T07:28:49.17+00:00

    Azure confirmed its known issue and has provided an estimated fix date of the end of September

    Was this answer helpful?

    0 comments
  3. Peter Bollwerk 56 Reputation points
    2026-08-12T15:41:40.1+00:00

    This started happening for us on July 30th with all of our Express Route circuits.
    I am opening a ticket for this now.

    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.