Document Intelligence: ProcessedPages metric and AnalyzeDocumentFromStream operation stopped being recorded - retired or regression?

Alex Lin 0 Reputation points
2026-08-05T09:30:34.6133333+00:00

Summary

On two independent Azure subscriptions (different tenants), the Document Intelligence ProcessedPages platform metric matched billed page usage exactly through late July 2026, and has since stopped emitting entirely. In the same hours, the DocumentModels_AnalyzeDocumentFromStream operation has disappeared from the TotalCalls dimension split, while the polling operation DocumentModels_GetAnalyzeResult is still recorded normally.

Analyze requests still succeed and are still billed. We can see that the service was used, but no longer how many pages were processed.

I could not find a retirement notice, and the documentation still lists ProcessedPages under the USAGE category: https://learn.microsoft.com/azure/ai-services/document-intelligence/how-to-guides/estimate-cost

Is this an intentional change (and if so, what replaces it), or a regression?

Setup (identical on both resources)

  • kind = FormRecognizer, sku = S0, location = eastus
  • Model prebuilt-layout, API version 2024-11-30 (v4.0 GA)
  • Client: azure-ai-documentintelligence 1.0.2, azure-core 1.35.0 (Python)
  • Billed under service Foundry Tools, meter S0 Pre-built Pages

How I queried

az monitor metrics list at --interval PT1H, in windows of 10 days or less, cross-checked against Cost Management UsageQuantity.

Note for anyone reproducing this: querying a wide range (e.g. 65 days at PT1H) silently truncates the result - whole months disappeared with no error or warning. That cost me a day of wrong conclusions. Query in short windows.

Resource B - the clearest case

Submits = TotalCalls split by OperationName = DocumentModels_AnalyzeDocumentFromStream. All times UTC.

Hour Submits Polls ProcessedPages Status
2026-06-01 00Z 224 756 1990 OK
2026-06-05 11Z 364 1413 1369 OK
2026-06-10 07Z 2 5 119 OK
2026-06-15 06Z 3 6 9 OK - 3 documents x 3 pages, verified by hand at the time
2026-06-26 06Z 1 2 16 OK
2026-07-02 07Z 2 7 17 OK
2026-07-03 09Z 18 45 161 OK
2026-07-06 10Z 1 3 4 OK
2026-07-13 03Z 2 5 60 OK - matches billed usage exactly
2026-07-22 03Z 1 3 36 OK - matches billed usage exactly
2026-08-05 08Z 0 1 0 broken

Resource B had no usage between 2026-07-22 and 2026-08-05, so the change happened inside that window.

Resource A

Hour Submits Polls ProcessedPages Status
2026-06-25 07Z 2 5 208 OK
2026-06-25 08Z 2 8 208 OK - 416 total for the day, exactly the billed page count
2026-07-16 07Z 0 4 0 broken
2026-07-16 08Z 0 5 0 broken
2026-07-16 10Z 8 92 8 partial - the day billed 59 pages, only 8 recorded
2026-08-05 03Z 0 31 0 broken
2026-08-05 04Z 0 31 0 broken

Resource A shows the first partial failure on 2026-07-16, earlier than Resource B.

Controlled test, 2026-08-05

Three prebuilt-layout analyze operations, all confirmed successful in application logs:

Resource Submit (UTC) Pages Client-side HTTP Duration Recorded by Azure Monitor
A 07:35:46 3 1 POST + 2 GET 5.3 s nothing at all in the 07Z bucket, 89 min later
B 07:52:41 3 1 POST + 3 GET 10.3 s nothing at all in the 07Z bucket, 72 min later
B 08:12:41 3 1 POST + 3 GET 10.4 s submits 0, polls 1, pages 0, 52 min later

The third test re-submitted byte-identical content to a file that was counted correctly on 2026-06-15 (part of the 9-page row above) - same resource, same content, same API, same client. Counted in June, not counted in August.

Ingestion latency is about 3 minutes, not hours - the third test's polling GET appeared within 3 minutes. So the missing submits and pages are not an ingestion delay.

Already ruled out

  • Resource configuration: a full ARM property diff of both accounts differs only in id and internalId (identical kind, sku, location, apiProperties, networkAcls, publicNetworkAccess, disableLocalAuth)
  • API version: ApiName dimension reads Azure AI Document Intelligence 2024-11-30 on both
  • Region: Region dimension reads East US on both
  • Client SDK versions unchanged across the period
  • Request shape unchanged across the period
  • Not routed through an AIServices/Foundry account (all requests go straight to the Document Intelligence endpoint)
  • Billing meter unchanged
  • Not throttling: BlockedCalls, ClientErrors, ServerErrors are all 0
  • Not request volume: the controlled test used 3-4 requests, the same volume as the June/July runs that were recorded correctly
  • No Service Health events on either subscription

Secondary question

On Resource A on 2026-08-05, every metric under-reports by roughly the same factor: 188 real HTTP requests produced TotalCalls 31, SuccessfulCalls 39, Ratelimit 34 data points and Latency 36 samples. Note SuccessfulCalls (39) exceeds TotalCalls (31) for the same resource and hour, which should be impossible for exact counters. Is that expected?

Questions

  1. Has ProcessedPages been retired, changed, or moved to a different metric namespace? If so, where is the notice and what is the replacement?
  2. Why has DocumentModels_AnalyzeDocumentFromStream stopped appearing in TotalCalls while DocumentModels_GetAnalyzeResult is still recorded in the same hour on the same resource?
  3. Can the missing data be backfilled?
  4. Is there any way to get billed page counts sooner than Cost Management's T+1?

We relied on ProcessedPages metric alerts for near-real-time cost control (a single past incident cost us a significant amount in runaway page charges). Those alerts now can never fire and never error - monitoring that silently stopped protecting us.

Azure Document Intelligence in Foundry Tools
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jerald Felix 18,760 Reputation points Volunteer Moderator
    2026-08-05T16:14:57.58+00:00

    Hello Alex Lin ,

    Greetings! Thanks for raising this question in the Q&A forum.

    This looks like a genuine platform-side regression rather than a retirement or a client-side mistake, and your diagnostics already rule out everything on the customer side. I could not find any retirement notice, deprecation announcement, or known-issue entry for ProcessedPages or the DocumentModels_AnalyzeDocumentFromStream operation dimension, and the documentation you linked still lists ProcessedPages as a current USAGE metric. That gap between documentation and observed behavior, combined with the SuccessfulCalls exceeding TotalCalls anomaly you found, points to a break somewhere in the metrics emission or aggregation pipeline for this resource type, separate from the billing pipeline (which is why billing still works correctly while the metric goes silent).

    Here is why this happens and what to do about it.

    Billing and Azure Monitor metrics are separate pipelines. Document Intelligence emits usage to the billing/metering system and, independently, publishes ProcessedPages and per-operation TotalCalls to Azure Monitor. When Azure Monitor's ingestion or aggregation layer for a given metric definition breaks, requests keep succeeding and keep being billed normally, but the platform metric stream for that dimension goes silent or partial. This matches your observation exactly: billed usage continued while ProcessedPages and the DocumentModels_AnalyzeDocumentFromStream split of TotalCalls stopped.

    This is not an ingestion delay. You already confirmed this with your controlled test (GET polling appeared within 3 minutes while the submit and page count never appeared after 52 to 89 minutes), so there is no need to wait longer or re-query.

    The SuccessfulCalls > TotalCalls inconsistency on Resource A is a strong signal of a genuine backend aggregation defect, not a display quirk. Exact counters should never allow a derived/split metric to exceed the parent counter for the same resource and hour.

    Open an Azure Support case, since this cannot be diagnosed or fixed from the customer side. Use:

    • Service: Azure AI services → Document Intelligence
      • Problem type: Monitoring and metrics (if that subtype isn't listed, use Service and application issues)
        • Severity: at minimum B (Moderate) given the loss of cost-control alerting; escalate to A (Critical) if you can show current production impact (for example, if a runaway-cost scenario is presently unmonitored)
          • In the case body, include: both resource IDs (or names/subscription IDs), the region (East US), API version 2024-11-30, the exact timestamps and results from your controlled test on 2026-08-05 (the 07:35:46 and 07:52:41 and 08:12:41 UTC submits), and the SuccessfulCalls/TotalCalls mismatch numbers from Resource A. Support engineers can pull backend telemetry pipeline logs that aren't visible to you, which is the only way to confirm whether this is a regional rollout regression, a schema change to the metric definition, or an ingestion bug.
          While waiting on Support, do not rely on ProcessedPages alerts for cost control. As a stopgap, use Cost Management's UsageQuantity (T+1, as you noted) or, if you need something closer to real time, send Diagnostic Logs for this resource to a Log Analytics workspace and alert on request logs directly rather than the platform metric, since your data shows the request/response logging path (via DocumentModels_GetAnalyzeResult polling) kept working even while TotalCalls/ProcessedPages did not. On backfill: Azure Monitor platform metrics are not retroactively backfilled once a gap has occurred; this needs to be confirmed by Support, but historically these gaps are permanent from the metrics store, so Cost Management/UsageQuantity is your authoritative source of truth for the affected window regardless of outcome.

    If this answer helps you kindly accept the answer which will help others who have similar questions.

    Best Regards,

    Jerald Felix.

    Was this answer helpful?

    0 comments

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.