Azure AI Document Undersstanding - Quotas and Metrics

Focus on page‑based metrics, not request metrics.I don't see any page-based metrics on the Metrics page. Am I looking in the wrong place?

"This kind of behavior usually happens when the service is busy or throttled, not because the request is completely lost"

This doesn't seem to match what we're seeing. Just today we had about 30 documents work fine over a 30 minute period. An hour later we submitted 8 documents, 5 worked fine and 3 documents never responded for the entire day. A few hours later we submitted about another 20 and again 6 of them still haven't responded. It seems that those docs are in fact "lost". Just now (a few hours later) I re-submitted one of the "lost" docs and it returned fine about a minute later. The original submission still hasn't returned. So, I think it's something more than just "This can look like AnalyzeAsync never returning". I'm pretty sure it is, in fact, never returning.

I run with these options, but I don't think the Retry is ever being invoked. When I run with Diagnostics on I just see the endless polling for status every 2 seconds.

     var clientOptions = new ContentUnderstandingClientOptions() {
         Retry =
                 {
                     Delay = TimeSpan.FromSeconds(30),       // The initial delay between retries
                     MaxRetries = 2,                         // The maximum number of retry attempts
                     Mode = RetryMode.Exponential,           // Use exponential backoff mode
                     MaxDelay = TimeSpan.FromSeconds(60),    // The maximum delay allowed between retries
                 },
         Diagnostics = {
                     IsLoggingContentEnabled = true,
                     IsLoggingEnabled = true,
                     }
     };

Thanks for the detailed explanation. What you are describing does help clarify the behavior, and I agree this feels different from simple short‑term throttling.

In Azure AI Document Understanding, when you submit a document for analysis, the service accepts the request first and then processes it asynchronously in the backend. Quotas and throttling are enforced at the processing layer, not at request submission. Because of that, a request can be accepted successfully but later get stuck in the processing queue when the service is under pressure.

When this happens, the request is not actually lost, but it may never reach a state where it completes or fails. From the client side, this looks like AnalyzeAsync never returning and endless polling, exactly as you are seeing. The retry policy you configured does not trigger in this case because there is no transport error, timeout, or failed HTTP response. The service keeps returning a valid status response, so the SDK believes the request is still in progress and continues polling.

This also explains why re‑submitting the same document later works fine while the original submission never completes. The second request is treated as a new job and may land on a healthy backend path, while the original job remains stuck in a degraded processing state.

This behavior is most commonly seen during periods of uneven load or partial service degradation. It does not affect every request, which is why you see some documents complete successfully in the same time window while others remain pending for hours.

A few practical things to consider when handling this pattern:

If a document stays in running or notStarted state for an unusually long time, it is safer to treat it as a stalled job and resubmit it with a new operation rather than waiting indefinitely.

Client retries only help for transient HTTP failures. They do not help when the service has already accepted the request and the job is stuck server‑side.

Tracking operation duration on your side and applying a maximum wait time per document is usually more reliable than relying only on SDK retries.

This behavior is also why Microsoft documentation focuses on page‑based quotas and processing capacity rather than request count. Requests can be accepted even when processing capacity is temporarily constrained.

the async analyze behavior is explained here https://learn.microsoft.com/azure/ai-services/document-intelligence/how-to-guides/use-sdk-rest-api

Your diagnostics output is consistent with how the service behaves when a job is accepted but never reaches completion. It is not that the request disappears, but that it never exits the processing pipeline.

We are currently reviewing the details. The team is actively working on the investigation, and we will update you as soon as we have more information. Thank you for your patience.

Thanks for the detailed response. I have made some significant changes to my AI application which seems to have mitigated the problem in dev. Most significant change has been to limit the number of pages sent to the AI. For our application, within the first few pages of a multi-page doc we have most of the information we need. So, if the PDF has more than 5 pages, we split it and only send the first part. We just only moved that into production, but we expect it to reduce if not eliminate the issue.