Category 6 of 10
Error handling and recovery
Failures are visible to the user and in logs, bounded in time, and free of internal detail.
v1.0 · verified on 2026-09-21
Failures must be visible and bounded. These items inject faults and time the result.
Failures surface to the user and to logs
automated Force a failure in each critical flow's backing call (database, payment, email, model).
The user sees a specific message and a log entry with a request id exists for every forced failure.
No infinite loading states
automated Block the network mid-request on each critical screen.
Every loading state resolves to an error or retry state within 10 seconds.
Error responses contain no internal detail
automated Trigger 4xx and 5xx responses on API routes and read the bodies.
No stack trace, file path, SQL text or provider error string appears in any response body.
External calls have timeouts and bounded retries
manual Review each outbound call site for a timeout and a retry limit; confirm with a stalled-endpoint test.
Every outbound call has a timeout under 30 seconds and at most 3 retries with backoff, or a documented exception.
Empty results and errors are distinguished
manual Open each list and detail screen with an empty dataset and with a failing backend.
Empty data shows an empty state; a failing backend shows an error state; neither is shown in place of the other.
Dots: Starter, Growth, Scale. Compare plan limits.
Failure patterns these items catch
- highException caught and dropped
A catch block logs nothing and returns a default, so a failed write looks like success to the user and to the team.
- mediumLoading state that never resolves
When a request fails, the loading flag is never cleared and the screen spins forever.
- mediumStack trace or query text in the response
Error responses include internal paths, SQL or provider messages that help an attacker and confuse a user.
- mediumRetry loop without backoff or limit
A failing call is retried immediately and indefinitely, turning one outage into a flood.
- mediumOutbound call without a timeout
A hung third-party request holds the connection and the user until the platform kills it.
- mediumEmpty result treated as an error, or the reverse
An empty list shows an error screen, or a failed query shows 'no items yet', and in an agent workflow an empty result is treated as a bug to fix.
Ask which plan runs these items
Email with your team size, cadence and stacks. We reply within 24 hours on business days.