19 patterns in this category — each with its illustration, what it is, and the fields that matter when you build or review one. Part of the UX pattern catalogue; the raw, agent-readable version is ux-pattern-catalogue/error-handling-patterns.json.
Wrap every route-level component and any component making async calls in an error boundary that catches rendering errors. Show a fallback UI with error context and a retry/reset button. Log the error to a tracking service (Sentry, LogRocket).
Page has independently-functioning sections (sidebar, main content, widgets). Wrap each section in its own error boundary so a failing widget doesn't crash the entire page. At minimum wrap: (1) root layout, (2) each route/page, (3) each data-fetching widget.
Log every caught error with type, message, component stack, user context (ID, page, action), and breadcrumbs (last 5 user actions). Rate-limit to avoid flooding. Never swallow errors with empty catch blocks — they hide bugs.
Set explicit request timeouts — 5-10 seconds for data fetches, 30 seconds for uploads. Show a specific "Request timed out" message with a retry button rather than letting requests hang indefinitely or showing "Unknown error".
Retry transient failures (5xx, timeout, network error) up to 3 times with exponential backoff (1s → 2s → 4s) and jitter (±20%) to avoid thundering herd. Show retry status to the user. Never retry 4xx client errors.
Listen to `navigator.onLine` and `offline`/`online` events. When offline, show a persistent banner and disable actions that require network. Never fail silently when offline or show generic network errors for a known offline state.
When users perform actions while offline, queue mutations in localStorage or IndexedDB and replay on reconnect in order. Show sync status. Handle conflicts with last-write-wins or by prompting the user. Never discard user actions due to temporary offline state.
Friendly page with a clear "Page not found" message, search bar, links to popular pages, and a "Go home" button. Tone is apologetic: "We can't find that page" — never blame the user. Optionally auto-redirect to home after 10 seconds.
Apology page with a "Something went wrong" message, retry button, status page link, and support contact. Show a reference ID for support tickets. Never show stack traces or suggest the user caused the error.
Explain why access is denied. If authentication is needed, show a login button. For sensitive resources, treat 403 like 404 to avoid revealing resource existence. Always provide a clear next action.
Show an estimated time of return (ETA), link to a status page, and an option to get notified when back (email input). Style consistently with the app. Serve as a static page that doesn't depend on the application server.
User has no items in a collection (no projects, no messages). Show an illustration/icon, a brief explanation of what will appear here, and a primary CTA to create the first item. Make the CTA the most prominent element — capitalize on motivation (Fogg Behavior Model).
Search or filter returns zero results. Show what was searched, suggest corrections ("Did you mean...?"), offer to clear filters, and link to browse all items. Never show an empty page without context about why it's empty.
User has completed all items (empty inbox, no pending tasks). Show a positive, celebratory message with an illustration and suggest a next action: "Review completed items" or "Create a new project." This is an achievement, not an error.
Data failed to load — this is not a real "empty" state, it's a masked error. Show error context, a retry button, and alternative navigation. Never show "No items" when the real problem is a failed API call.
Cache the app shell (HTML, CSS, JS) and critical data so the app works offline or loads instantly on repeat visits. Use stale-while-revalidate for dynamic data. Clear stale caches on new deployments.
Show a non-dismissible banner at the top when the user goes offline: "You're offline — some features may be limited." Remove automatically when connection restores. Use warning color (yellow/amber), not error (red) — offline is a state, not an error.
When connection restores, replay queued mutations in order. Show sync progress. Handle conflicts (server data may have changed). Notify on completion. Never silently sync without notifying or overwrite newer server data with stale offline data.
For mutations with high success probability (likes, toggles, simple creates), update the UI instantly, queue the server request, and roll back on failure with an error toast. Never use optimistic writes for destructive actions (delete, payment) — wait for server confirmation.