Backrest's own error API caps at 21 entries, and an operator chased a fix that had already worked

Backrest’s operations API returns at most 21 error entries per run. This is a documented display limit and not a bug. But the summary reads as a count, and a count is what anyone looking at it will act on.

The effect on the work was almost backwards from the usual monitoring failure. Excluding a known-noisy file from a backup run removed one error, which freed a slot, which another genuinely failing file promptly filled. The reported total stayed pinned at exactly 21 across roughly 180 runs. Every exclusion added looked like it had accomplished nothing, when in fact each one had worked exactly as intended. This was not a false alarm; it was a false absence of improvement, which is harder to notice because nothing about it feels wrong. Checking the true count for one run directly gave 39, nearly double what the API reported.

The fix was to stop asking the convenience layer and read the tool’s own internal database, a SQLite log it maintains, for anything that needs to be a total.

The habit worth generalising is a trigger rather than a rule. When a number stops responding to a change that should have affected it, suspect the number before concluding the change did nothing. A capped list masquerading as a complete answer does not fail loudly; it tells a partial truth that happens to look total, and it will keep doing so indefinitely. Any count arriving through a summary or convenience API, particularly a third-party one, deserves that suspicion the first time it refuses to move.