Errors must be counted separately as recoverable and unrecoverable; merged counts hide severe problems

What it is

"Made one mistake" and "one mistake ends the task" are different facts: recoverable errors (a mis-click immediately corrected) are digested by users themselves; unrecoverable errors (overwritten data, double-submitted orders, no way back) cause real loss or task termination. Merged into one error total, a mass of light errors drowns the handful of fatal ones in the statistic.

Why it happens

The two classes have entirely different cost functions: a recoverable error costs seconds of redundant operation; an unrecoverable one can cost redoing all the work or permanent loss. What actually demands design intervention is the second class—it exposes missing prevention and exit mechanisms. The arithmetic harm of merging is that totals dominate rankings: an interface with few errors but one unrecoverable one ranks above an interface with many errors that are all recoverable, while the true risk ranking is reversed.

Studying it

Encode recovery status into the error record: occurrence, noticed or not, self-recovered or not, recovery time, and consequence tier when unrecoverable. Report the two counts and a recovery-success rate separately; unrecoverable errors go on their own defect list, never diluted into averages. In log data, undo/back sequences identify recoverable errors and "mid-task termination following an error" flags suspected unrecoverable events for human verification.

Where it stops holding

Recoverability is relative to task and data state: in draft contexts almost everything recovers, in payment contexts most errors do not—their rates do not compare directly. "Self-recovered" leans on the user's experience reserve: experts recover from more than novices do, so the same error is unrecoverable for a novice—tier the statistics by experience group. Recovery cost is also graded; the binary split is a simplification.

Applying it

• Fix recovery fields in the error template: noticed, recovery method, time cost, consequence tier.
• Grade acceptance: unrecoverable errors get their own threshold (ideally zero), never blended into the total error rate.
• Lay prevention layers (confirmation, re-entry, soft delete) under high-risk operations; the goal is emptying the unrecoverable class, not lowering the total.

Related

• Same group: B5.10.1 Error rate correlates with effectiveness but must be reported separately; their remedies differ · B5.10.3 A zero-error interface may just have converted errors into abandonment · B5.10.4 Error rate responds to interface changes more sensitively than satisfaction, making it a good regression monitor
• Nearby: I1 State, Time, and Response · Y1 Safety-Critical Interaction
• Search terms: error recovery · recoverable errors · error severity