# Count recovered work as well as successful sign-ins

Authentication metrics do not show whether users returned to their task. Measure draft recovery, duplicate avoidance and context correctness after expiry.

By Cobnex editorial. Published 2026-09-10. Updated 2026-09-11.

## Follow the interrupted journey

Track an expiry interruption through authentication and return to a usable task state. Distinguish a restored draft, a recovered completed result and a deliberate access denial.

A successful sign-in followed by an empty form is not a successful recovery. Likewise, an account whose permission was revoked should not count as a defect merely because the previous action remains unavailable.

Use state categories and correlation identifiers without placing tokens or draft contents in telemetry.

## Measure lost work directly

Record whether previously saved fields and attachment references survive the supported recovery path. Use controlled fixtures to verify this property and support reports to identify failures in real use.

An illustrative test has twenty interrupted drafts. Nineteen restore correctly and one loses its uploaded reference. Reporting a 95 percent recovery rate is useful, but the missing attachment still needs a specific defect and owner.

Separate unsaved work from data the interface claimed was saved. Both may affect usability, while the latter also indicates a broken product promise.

## Check for duplicate and wrong-context actions

Compare recovered command IDs with resulting business records. A retry sequence should not create another action when the original already succeeded.

Include account and organisation changes in acceptance fixtures. Zero observed cross-account incidents is not proof of isolation unless the boundary is deliberately tested.

Monitor repeated authentication loops and concurrent-refresh failures. They can indicate coordination problems rather than incorrect user credentials.

## Evaluate the interruption's usability

Observe whether people understand what remains saved and what they need to do next. Measure return-to-task time separately from the identity provider's sign-in time so the application recovery path is visible.

Test warnings and reauthentication with the supported interaction methods. Apply the relevant timing requirements to the complete process, not only the login form.

A release is ready when supported interruptions produce an explainable outcome: restored work, an existing receipt or a clear current-access decision. A high authentication success percentage alone does not establish that result.

## Sources

- [OWASP: authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
- [W3C WAI: timing adjustable](https://www.w3.org/WAI/WCAG22/Understanding/timing-adjustable.html)