On this page
The short answer
Monitor freshness by tracing a known source revision through parsing, indexing, retrieval, and answer generation. Check the version actually served, not just the last successful ingestion job or the time a search request ran.
What to take away
- Probe a known changed fact.
- Track timestamps across stages.
- Separate stale evidence from wrong inference.
Sources checked . Research synthesis and Rubrex recommendations. Examples and local experiments are labeled; they are not client results.
Define freshness as an observable interval
Azure’s indexer documentation describes detecting changes and resynchronizing indexed content. For monitoring, identify the source event that starts your freshness clock and the user-visible condition that ends it. A file modification time, event receipt, completed ingestion job, and first correct retrieval are different milestones. Write the intended service expectation before building an alert. Without that definition, a green job dashboard can coexist with answers still based on an old cached passage.
Evidence: Run or reset indexers [1]Change and delete detection using indexers [2]
Create a versioned sentinel
Maintain a synthetic, non-sensitive test document with a revision marker and a fictional availability fact. Change the fact from state A to state B through the normal source workflow. Probe the exact supporting evidence and its revision, then ask the application a question that requires the changed fact. The fixture passes when the expected eligible revision is retrieved and used within the locally agreed window. It should not depend on a model copying a hidden evaluation token.
Locate the stage where time is lost
Record source-update time, source-reader observation, parsing completion, indexing acknowledgment, successful direct lookup, search retrieval, and cached-context revision where available. If the new record is retrievable but the answer uses an old cache, the ingestion pipeline is not the first broken stage. If direct lookup is current but ranked search is stale, inspect indexing consistency or query routing. Keep service errors separate from confirmed stale reads so outages are not misreported as ordinary propagation delay.
Avoid a monitor that tests only itself
A sentinel query can be easier than production questions because it contains an exact revision marker. Pair it with a natural question about the changed fact and occasional sampled real updates under approved data handling. Cover the retrieval routes the application actually uses, including hybrid search and parent expansion. Do not publish synthetic monitor documents into ordinary customer search results. Their purpose is to make the pipeline observable without contaminating the knowledge users rely on.
Respond with a bounded remediation policy
Choose alert thresholds from the consequence of stale facts and the system’s observed behavior rather than a generic minute count. Specify whether the application can serve older evidence with a date qualification, bypass a cache, or decline a time-sensitive answer. Test the fallback with the sentinel. Retain enough stage timestamps to explain an alert after recovery, while avoiding unnecessary copies of source data. Review freshness failures alongside answer applicability, because current indexing cannot repair a wrongly interpreted effective date. Check clock alignment before interpreting small delays. Inconsistent source and application clocks can create negative or misleading intervals even when the pipeline stages are correctly instrumented.
Limits of the evidence
This is a monitoring design, not measured indexing performance or an uptime commitment. Sentinel success does not establish freshness for every document or retrieval route.
Common questions
Is the last successful job timestamp enough?
No. It does not show which revision is retrievable or whether a cache still serves old evidence.
Should monitoring use real customer data?
Use synthetic probes where possible and sample real changes only under the agreed data-handling policy.
Sources & further reading
Primary sources behind this briefing. A source’s findings apply to its own study conditions; publication on arXiv does not establish peer review.
- Run or reset indexers Microsoft · Living reference · Maintained documentationReviewed: indexer change tracking, reset and resynchronization distinctions. Accessed October 16, 2026.
- Change and delete detection using indexers Microsoft · Living reference · Maintained documentationReviewed: change tracking and explicit deletion detection requirements. Accessed October 16, 2026.
Questions or corrections? Write to Rubrex. Read our editorial approach.