Replace 'Something went wrong' with actionable error recovery

Why generic errors become tickets

A person hits an error. Your app catches the exception and shows "Something went wrong. Please try again." The real cause is in the server log (a rejected VAT number, an expired session, a file your endpoint will not accept), but none of that reaches the user. They try again. Same message. They write to support, your team reconstructs the failure from logs, and the ticket closes with "here is what actually went wrong."

Every one of those tickets is a blocked customer who could not finish, and your support team answering the same question the server already knew. Scritch reads what the server knows, explains it in plain words, and where it can, fixes the failure with the user's approval.

What Scritch does instead

When your app catches an error, Scritch reads the real failure: the server's response, the rules your form never surfaced, and whatever your error monitor, auth provider or status page already knows. It asks the user the one thing no tool can tell it, in plain words. If the fix needs their approval, it shows exactly what will change and what can be undone. It proves the fix worked before anyone is told they are unblocked. The ticket is never filed.

A rejected invoice becomes "Your VAT number is registered in the Netherlands but the billing country is Belgium, and the form never surfaced that rule. Belgium is right?" The user answers, approves the fix, and the invoice goes through. An expired session becomes "Your sign-in expired about forty minutes ago, so the save was rejected. Your draft is safe. Sign in again here, then press Save." The user signs in and carries on.

What you get

• Fewer tickets. Every recovery is a support email your team never sees. The failures that generate the angriest tickets (rejected uploads, expired sessions, forms that refused them for a rule they never saw) are the ones the agent handles first.
• Happier users. A blocked person gets unstuck in the moment, in your app, instead of waiting for business hours and explaining it again.
• Better signals. Your console shows every recovery, what went wrong, and whether the agent fixed it or escalated it. The trail your team used to reconstruct from a ticket is already there.

How to replace your generic errors

Install the SDK (npm install scritch-react), wrap the failing call in useRecoverableTask, and render the guidance it returns where the error message used to go. The agent reads from read-only tools you register with your own credentials, asks one question in plain words, stops for approval before changing anything, and proves the fix before saying so. Integration is one hook and about five minutes. Start with the failure your queue hears about most.

See the live demo, grade your own error in the free error message checker, or create a workspace to try it on your own app.