Begin with a catalog denominator, not a dashboard number
A museum replaces an old search index with a rebuilt catalog index containing objects, captions, and rights-approved descriptions. The search dashboard shows a document count, but curators need to know whether every eligible accession record is available. Those are different questions. Azure AI Search exposes per-index statistics, including document count and storage use. These metrics describe the search service’s current index state; they do not say which accession numbers should exist or whether public rights were approved. Before reading the statistics endpoint, define the scope of eligible source records and the time of the source export. Keep restricted, unpublished, and superseded items in separate categories rather than treating every mismatch as a missing public object.
Request per-index statistics using the supported API
Microsoft documents an Indexes—Get Statistics operation that returns a document count and storage usage for a named index. The REST path and API version should be taken from current documentation for the service version you use. Authenticate through an approved identity or API key with appropriate permission and keep credentials out of article examples, client-side scripts, and ordinary logs. Save the index name, time of the query, and returned values in an internal operations record. A successful HTTP response means the metrics were retrieved; it does not certify the index’s source provenance, security settings, or the success of every preceding indexer task.
Distinguish document counts from accession counts
One museum object can produce multiple searchable documents when a source is divided into pages, passages, image captions, or language variants. Conversely, two source rows can collapse into one target document if their keys collide. The index documentCount metric cannot resolve either case by itself. Define a mapping from each expected source accession identifier to its intended target document IDs, including legitimate child records. Report separate counts for eligible source records, expected indexed documents, actual indexed documents, and checked source links. If these denominators differ, explain why before publishing an index coverage percentage. Counting raw records without the mapping risks overstating completeness or mistakenly labeling legitimate chunks as duplicates.
Interpret storageSize without inventing file integrity claims
The per-index statistics endpoint includes storage usage, but storageSize is not a hash of original museum files and is not a measure of preservation quality. It can change with indexing structures, vector content, updated documents, and internal service activity. Microsoft notes that service-level and index-level metrics can be collected independently and may temporarily disagree because of different collection intervals. Do not use a storage figure to infer that every scan was preserved at full resolution or that all captions were indexed. For preservation integrity, maintain original object checksums and a separate archive inventory. The search index is a retrieval layer, not the authoritative preservation store.
Recognize metric lag and index maintenance
A change in documentCount may lag behind a catalog export or a rebuild schedule. Microsoft troubleshooting guidance also describes temporary storage effects while background merges clean up old versions. Capture comparable timestamps and avoid interpreting a short-lived disagreement as automatic corruption. An operator should check the indexer history and source change log when metrics appear inconsistent, then repeat the measurement after the relevant processing window if appropriate. These steps require legitimate environment observations; this article does not provide synthetic benchmark measurements. Do not silently modify live index settings solely because a metric moved. Record the discrepancy and identify the source-of-truth records that may be affected.
Compare three separate kinds of evidence
Illustrate the workflow with a source ledger containing approved accession IDs, a metric snapshot showing index documentCount and storageSize, and a lookup audit that confirms individual records. Each is useful for a different purpose. The source ledger defines the intended public catalog. The statistics operation shows what the index reports at a point in time. The lookup audit checks that representative identifiers resolve to the correct source documents. A green status on the metric panel should not be drawn as automatic publication approval. Only after those three views have been reconciled can staff explain whether an apparent shortfall is a genuine missing object, a chunking difference, or a timing discrepancy.
Build a targeted missing-record investigation
Start with a small list of accessions that should appear in the index but do not show in a controlled search. Check the source eligibility rules, data source connection, indexer outcomes, document key derivation, and the application’s query filters. Test a known public record and a deliberately restricted record to confirm the user-facing behavior. A restricted record absent from public results can be correct even when it is indexed behind an authorized route. Avoid counting it as a failure without examining the access policy. For each unresolved candidate, retain its accession ID and evidence path rather than producing an unsupported summary such as ‘the indexing system lost several objects.’
Watch retrieval quality in addition to counts
A full document count does not mean the index will retrieve the right objects. Tokenization, analyzer configuration, synonym behavior, field selection, filters, and relevance settings can all affect what a user sees. Keep a curated query set covering unusual spelling, historic part numbers, object creators, and titles containing punctuation. Compare results with the approved catalog, ensuring relevant records are findable without leaking restricted data. Record missing or ambiguous hits as quality issues even if the overall documentCount appears stable. Metrics are useful triggers for investigation, but operational acceptance should also include search relevance and provenance checks for representative, authorized records.
Use staging and a signed release reconciliation
For an index rebuild, collect a source manifest with the planned eligible records and the expected transformation from each record to target documents. Build and test in staging, capture per-index statistics, and review a reconciliation report before any application routing change. Include a rollback plan, source version, index schema version, and a staff sign-off for public catalog content. If the source export changes while verification is underway, start a new comparison window rather than mixing the denominators. A successful deployment command should not replace the curator’s check that the retrieved caption and object identity are still correct.
Keep statistics in their proper operational role
Present monitoring with clear labels: index metric snapshot, expected source coverage, outstanding reconciliation cases, and last staff approval. Store metric changes historically so operators can investigate trends without pretending each change is a lost record. Restrict dashboard detail when even metadata about private collections may be sensitive. When metrics drift, diagnose collection timing, chunking rules, failed indexing, and source changes before taking action. The goal is a reliable catalog search experience supported by traceable source IDs, not a dashboard that looks complete because the documentCount appears plausible. Recheck official endpoint behavior and quotas whenever the service version or monitoring approach changes.
How We Research
We reviewed the named official developer references Microsoft Learn: Indexes—Get Statistics REST API, Microsoft Learn: Troubleshoot storage and metric discrepancies. We compared their documented request and delivery behavior, accepted configuration patterns, and explicit limitations with the proposed hypothetical museum workflow. This article is a source-based implementation guide: we did not execute live customer API calls, inspect private cloud accounts, run production tests, or measure latency, cost, or accuracy. Readers should verify current limits and deployment settings with the original documentation and run their own controlled staging tests before changing public systems.
Frequently Asked Questions
Not necessarily. One object may have multiple searchable chunks or languages, and key collisions can collapse entries.
No. It is a search-index storage metric, not a checksum of the original archive files.
Yes. Microsoft notes they may be collected at different intervals and can show temporary differences.
No. Reconcile expected source IDs, actual index documents, and verified lookups before making that claim.
Review source eligibility, indexer errors, key mapping, query filters, and authorized source-to-index lookups.