“Success rate” tells you whether pages responded, but “usable records” tells you whether the run produced comparable evidence. In monitoring, usable records is the metric that predicts whether a snapshot can be trusted across replays.
Define usable record in one sentence
A usable record is a parsed result that is complete enough to compare across replays of the same slice. If the record is missing required fields or came from a different locality signal than the slice definition, it is not usable for trend decisions.
What it changes in monitoring decisions
When you optimize for usable records, you stop chasing throughput and start controlling variance: pacing budgets, stable locality inside windows, and clear “non-comparable” outcomes become first-class results.
This also makes alerts safer: a breach in usable-record ratio is an input-quality signal, not automatically a market change.
Where teams misread the signal
The common misread is treating 200 OK as “good data”. Template variants, localization branches, and client-side rendering can all return 200 while silently dropping fields or changing layouts. That is why a run can look healthy while outputs become non-comparable.
When it does not fit
If the workload is one-off discovery rather than replayable monitoring, usable-record gates may be too strict. In that case, separate discovery traffic into its own queue so monitoring slices remain comparable.
FAQ
How do I measure usable records quickly?
Start with a small required-field set per template, then count how many records include all fields inside one window. Track the ratio per slice and alert on sustained drops.
Why can usable records drop without more errors?
Because the failure is often a template or locality shift, not an HTTP failure. You still get responses, but the outputs no longer match the slice definition.