UX Patterns Guide
Back to compare picker

Toast-only critical error vs Error state

Choose error state when a failed payment, save, upload, permission check, destructive action, or security step blocks progress or changes whether the current page can be trusted.

Toast-only critical error live exampleError state live example

Decision dimensions

Dimension Toast-only critical errorError state
UI or UX UI + UX - Transient critical-feedback anti-patternUI + UX - Recoverable failure surface
UI guidance Replace a lone disappearing toast with a persistent failure region attached to the affected task, using a heading that names the failed payment, save, upload, permission, or destructive action.Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance Protect users from losing the only explanation for a high-consequence failure by keeping the problem, affected object, and next action available after the notification times out.Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI A failed invoice payment leaves a persistent alert inside the invoice panel with Retry payment, Update card, and Contact billing actions.Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI A small Payment failed toast appears at the corner and disappears while the invoice panel shows no recovery action.Tiny transient toast for a blocking failure.
Good UX After the notification disappears, users can still see that the invoice is unpaid, why payment failed, and which recovery actions are available.User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX Users have to guess whether the payment, save, delete, or upload succeeded after the toast timed out.Clearing work after save failure.
Best fit Use this anti-pattern entry to identify and replace transient-only handling of payment, save, permission, account, upload, deletion, and security failures.A system or task failure blocks expected content or action.
Avoid when The message is a low-risk confirmation and no follow-up action is required.Nothing exists yet and the state is expected.
Required state Pre-action state that shows what the user is attempting and what will be affected.Normal expected state before failure.
Accessibility burden Do not rely on an auto-dismissing live-region announcement as the sole way to communicate a critical failure.Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse Showing Payment failed as a small toast while the invoice page returns to its normal paid-or-unpaid layout with no retry path.Using a transient toast for critical errors.

Toast-only critical error

UI or UX
UI + UX - Transient critical-feedback anti-pattern
UI guidance
Replace a lone disappearing toast with a persistent failure region attached to the affected task, using a heading that names the failed payment, save, upload, permission, or destructive action.
UX guidance
Protect users from losing the only explanation for a high-consequence failure by keeping the problem, affected object, and next action available after the notification times out.
Good UI
A failed invoice payment leaves a persistent alert inside the invoice panel with Retry payment, Update card, and Contact billing actions.
Bad UI
A small Payment failed toast appears at the corner and disappears while the invoice panel shows no recovery action.
Good UX
After the notification disappears, users can still see that the invoice is unpaid, why payment failed, and which recovery actions are available.
Bad UX
Users have to guess whether the payment, save, delete, or upload succeeded after the toast timed out.
Best fit
Use this anti-pattern entry to identify and replace transient-only handling of payment, save, permission, account, upload, deletion, and security failures.
Avoid when
The message is a low-risk confirmation and no follow-up action is required.
Required state
Pre-action state that shows what the user is attempting and what will be affected.
Accessibility burden
Do not rely on an auto-dismissing live-region announcement as the sole way to communicate a critical failure.
Common misuse
Showing Payment failed as a small toast while the invoice page returns to its normal paid-or-unpaid layout with no retry path.

Error state

UI or UX
UI + UX - Recoverable failure surface
UI guidance
Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance
Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI
Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI
Tiny transient toast for a blocking failure.
Good UX
User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX
Clearing work after save failure.
Best fit
A system or task failure blocks expected content or action.
Avoid when
Nothing exists yet and the state is expected.
Required state
Normal expected state before failure.
Accessibility burden
Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse
Using a transient toast for critical errors.
Decision rules
  • Choose error state when a failed payment, save, upload, permission check, destructive action, or security step blocks progress or changes whether the current page can be trusted.
  • Flag toast-only critical error when the toast is the only place that names the failed action, consequence, support reference, or recovery action.
  • Use transient toast feedback only for low-risk confirmation or background status when users do not need to act after the message disappears.
  • If a critical failure also triggers a toast, keep a persistent inline, section-level, modal, or page-level error that users can revisit after the toast closes.
  • Prefer an error state when users need retry, correction, fallback, undo, support escalation, or proof of whether an operation succeeded.
  • Do not auto-dismiss the only explanation for payment failure, failed save, failed delete, failed upload, access denial, or account/security failure.
  • Attach the recovery action to the affected object or task; do not make users hunt through a global notification list before they can repair the failure.
  • For form-wide or multi-field failures, pair the persistent error state with field-level validation or an error summary instead of relying on a toast.
Inspect live examples
Toast-only critical errorError state
Failure modes
  • A payment page shows a brief failure toast and then returns to a normal-looking unpaid invoice with no retry path.
  • A failed save clears a draft after a snackbar appears.
  • A permission error appears far away from the disabled or failed action.
  • A support reference disappears before the user can copy it.
  • Every backend exception is routed through the same global toast handler, hiding consequence and recovery differences.
  • A screen reader user hears the failure but cannot find a persistent action after the live-region announcement ends.