UX Patterns Guide
Back to compare picker

Toast-only critical error vs Error state

Use an error state for blocking or high-consequence failures; treat toast-only critical feedback as an anti-pattern unless a persistent recovery surface remains available.

Toast-only critical error live exampleError state live example
Learn the decision

Match the interaction to the person's task

Use an error state for blocking or high-consequence failures; treat toast-only critical feedback as an anti-pattern unless a persistent recovery surface remains available.

Toast-only critical error

Use it when: Use this anti-pattern entry to identify and replace transient-only handling of payment, save, permission, account, upload, deletion, and security failures.

Make this state clear: Pre-action state that shows what the user is attempting and what will be affected.

Observe the result: After the notification disappears, users can still see that the invoice is unpaid, why payment failed, and which recovery actions are available.

Study the full pattern →

Error state

Use it when: A system or task failure blocks expected content or action.

Make this state clear: Normal expected state before failure.

Observe the result: User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.

Study the full pattern →

Practice the judgment: Imagine this situation: A failed save clears a draft after a snackbar appears. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

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.Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI.
Good UI A failed invoice payment leaves a persistent alert inside the invoice panel with Retry payment, Update card, and Contact billing actions.A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation.
Bad UI The user misses the only error message and repeats the failed 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 A toast supplements a persistent error state, inline validation message, undo affordance, or notification center item that users can revisit.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 Place persistent error text and recovery controls in the reading order near the affected task.Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse Using a disappearing snackbar as the only feedback for failed save, failed delete, failed permission change, failed upload, or failed authentication.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
The user misses the only error message and repeats the failed 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
A toast supplements a persistent error state, inline validation message, undo affordance, or notification center item that users can revisit.
Required state
Pre-action state that shows what the user is attempting and what will be affected.
Accessibility burden
Place persistent error text and recovery controls in the reading order near the affected task.
Common misuse
Using a disappearing snackbar as the only feedback for failed save, failed delete, failed permission change, failed upload, or failed authentication.

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
Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI.
Good UI
A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation.
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.

Saved items