What is user-facing error recovery?
Last updated 3 September 2026
User-facing error recovery is the practice of turning an error a user hit into a fix they can act on, rather than a dead end. When a request fails — an invoice the server refused, a spreadsheet it would not import, an upload it rejected — recovery finds the real cause, asks the user only what the logs cannot tell it, makes the change with their approval, and proves it worked before saying so.
It is the layer between the error and the support ticket. Most software still answers a blocked user with “Something went wrong. Please try again,” which is true, useless, and the start of an email to support. Recovery answers the same failure with the one thing that unblocks it.
How is it different from error monitoring?
An error monitor — Sentry, and its kind — tells you that something broke: it groups exceptions, alerts an on-call engineer, and shows a stack trace. That is for the team, after the fact.
Error recovery is for the user, in the moment. It does not replace monitoring; it reads from it. The monitor is where the evidence lives; recovery is what turns that evidence into a resolved session instead of a lost one. If you already run Sentry, recovery sits on top of it rather than beside it. For a side-by-side, see Scritch vs. an error monitor.
What does a recovery actually do?
A single recovery runs in order, and stops the moment it needs a human:
- Reads the evidence — the failed request, the response the server sent, the code path that raised it.
- Asks one question, and only what it cannot find on its own — the fact that lives with the user, not in the logs.
- Changes nothing without approval — it proposes the fix and waits for the user to say yes.
- Proves the fix — it re-runs the thing that failed and confirms it now succeeds before reporting success.
- Hands off what it cannot fix — an escalation carries the whole trail, so the user never re-explains it to support.
Where does it fit?
Anywhere a blocked user costs a support ticket: onboarding, integrations, imports, billing — anything with a form a server can refuse. The failures worth recovering are the ones with a real cause the user can act on, not the transient blips a retry already handles.
Is it safe to let an agent change things?
Safety comes from two constraints, not from trust. First, nothing changes without the user’s explicit approval of that specific action. Second, the change is verified — the agent re-runs the failed operation and only calls it recovered once it actually succeeds. A recovery that cannot be proven is escalated, not claimed.
How Scritch does this
Scritch is an AI recovery agent that installs as one hook where your error message used to go. It reads, asks, fixes with approval, and proves the result, in your own UI and in the user’s language. See how it works, or the security questions a reviewer asks, on the home page.