Coverage
A customer must never believe they are covered when they are not.
That is the rule this page exists to keep. An empty drift report is ambiguous - conforming, or unwatched - and the ambiguity always resolves in our favour if nobody publishes the denominator. So we publish it.
Per operation: how many responses were seen, how many were actually weighed against the contract, and for every one that was not, the reason.
Sampling is not a bug
Checking every response of a busy API would cost more than the API, so the gateway validates one response in N and chooses N from the traffic it sees. Two numbers control it:
- a budget - at most so many validated responses per second, which bounds the cost however busy the operation gets;
- a floor - never longer than so many seconds without a validated response, so a quiet endpoint is covered rather than merely cheap.
Both are per operation, not per process. Your one hot endpoint must not be allowed to spend the whole budget and leave the other ninety uncovered, because coverage across the contract is the product; validated requests per second is not.
The 1 in N column is the divisor in force for that operation, and it
moves on its own as traffic changes.
The number that matters is not "100%". It is whether the sample is big enough to catch a problem, and whether the responses that were skipped were skipped for a reason you would have chosen.
The reasons
Every response is either checked or skipped for exactly one named reason, so the numbers add up and a gap has a name rather than a shrug:
| reason | what it means |
|---|---|
| not sampled | the sampler passed on it; raise the budget to see more |
| no schema declared | the document does not say what that response should look like |
| body too large | over the configured cap; the body streamed through untouched |
| not JSON | a content type there is no schema language for here |
| no body | nothing to check |
| would not decode | the body claimed JSON and was not |
No schema declared is the one to read twice. Those responses were not checked because your document does not describe them, and no amount of sampling fixes that - editing the document does. An operation sitting at 0% for this reason is an operation you believe is covered and is not.
Operations with no traffic
Listed separately and not counted as a failure. An endpoint nobody has called is not a coverage problem, and mixing the two would bury the ones that are.
Where the numbers come from
The gateway ships a snapshot on its own slow clock, about once a minute, riding the same channel as the violations. It ships even when there are no violations at all - which is the entire point, since that is exactly the case an empty drift report cannot explain.
Snapshots are assigned rather than added, so a retried batch writes the same numbers again and a restarted gateway replaces its history rather than being added to it.
If nothing has ever reported coverage for a proxy, the page says so plainly - and until it does, an empty drift report is not yet evidence of anything.
From a terminal
apip coverage 42