UX Patterns Guide
UI + UX Feedback, Status, And System State anti-pattern

Toast-only critical error

Treat the toast-only critical error as an anti-pattern: keep the failure and recovery controls persistently attached to the affected task, and use any toast as supplemental feedback only.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • Use this anti-pattern entry to identify and replace transient-only handling of payment, save, permission, account, upload, deletion, and security failures.
  • Use it during generated UI review when an event handler triggers a toast but leaves the page in a normal-looking state after a critical operation fails.

Avoid when

  • The message is a low-risk confirmation and no follow-up action is required.
  • A toast supplements a persistent error state, inline validation message, undo affordance, or notification center item that users can revisit.
  • The feedback is purely informational and does not affect whether users can trust the current task state.

Problem it prevents

A blocking or high-consequence failure is announced only in a transient toast, so users can miss what failed and lose the path to recover.

Pattern anatomy

What a strong implementation has to make clear

User need

A payment, save, permission, destructive action, security, or data-integrity operation fails.

Pattern promise

Treat the toast-only critical error as an anti-pattern: keep the failure and recovery controls persistently attached to the affected task, and use any toast as supplemental feedback only.

Required state

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

Recovery path

The user misses the only error message and repeats the failed action.

Access contract

Do not rely on an auto-dismissing live-region announcement as the sole way to communicate a critical failure.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • A failed invoice payment leaves a persistent alert inside the invoice panel with Retry payment, Update card, and Contact billing actions.
  • A short toast says Payment failed, but it links back to the same persistent invoice error that remains after the toast closes.
  • After the notification disappears, users can still see that the invoice is unpaid, why payment failed, and which recovery actions are available.
  • Retrying the failed operation preserves the payment or draft context and either returns to success or shows a still-failed state with escalation.
Weak implementation

Vague, hidden, hard to recover from

  • A small Payment failed toast appears at the corner and disappears while the invoice panel shows no recovery action.
  • A failed file upload reports Error in a snackbar, clears the selected file, and leaves no support reference.
  • Users have to guess whether the payment, save, delete, or upload succeeded after the toast timed out.
  • Keyboard and screen reader users hear a brief alert but cannot find the failed task or action afterward.
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.
  • If a toast is still useful for awareness, keep it short and supplemental while the full cause, consequence, reference, and recovery controls remain visible elsewhere.
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.
  • Design recovery around what users must do next: retry the operation, correct details, restore or undo a change, use an alternate route, or contact support with a retained reference.
Implementation contract

What the implementation must handle

States

  • Pre-action state that shows what the user is attempting and what will be affected.
  • Failed persistent state with the failed object, plain-language cause, and recovery actions.
  • Supplemental notification state that does not replace the persistent failure surface.
  • Recovered state after retry, correction, reversal, or support escalation succeeds.

Interaction

  • The critical error remains visible until it is resolved, intentionally dismissed from a safe persistent surface, replaced by a recovered state, or escalated.
  • The affected task stays connected to the recovery controls instead of making users search for the failed object after a notification disappears.
  • A toast may announce that failure happened, but it must not be the only place where the cause, consequence, support reference, or next action appears.
  • If the message auto-dismisses, users can still reach the same information and action from the failed task, notification center, activity log, or persistent error region.

Accessibility

  • Do not rely on an auto-dismissing live-region announcement as the sole way to communicate a critical failure.
  • Place persistent error text and recovery controls in the reading order near the affected task.
  • Use alert or status semantics according to urgency, but pair the announcement with visible text that remains available.
  • Respect reduced-motion and timing needs by avoiding flows where users must chase a moving or disappearing notification.

Review

  • If the user looks away for five seconds, can they still tell what failed and what to do next?
  • Does the recovery action remain attached to the invoice, form, file, or account setting that failed?
  • Would a screen reader or keyboard user be able to act after the transient announcement has finished?
  • Is the toast communicating low-risk status, or is it carrying the only explanation for a high-consequence failure?
Interactive lab

Inspect the states before you copy the pattern

Compare transient vs persistent error handling

Trigger both outcomes and inspect which one still supports recovery.

Toast-only critical error
Interactive demo is ready

Launch the live UI/UX lab when you want to inspect states, keyboard behavior, and common failure modes.

State To Inspect

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

Keyboard / Access

The recovery controls remain in the normal tab order after the toast closes.

Avoid Generating

Showing Payment failed as a small toast while the invoice page returns to its normal paid-or-unpaid layout with no retry path.
Evidence trail

Source-backed claims behind this guidance

Carbon Design System Notification

IBM Carbon Design System - checked

Carbon distinguishes inline, toast, actionable, and callout notifications; toast messages can auto-dismiss, while critical action or longer recovery needs persistent or actionable treatment.

Atlassian Design System Error Messages

Atlassian Design System - checked

Atlassian documents direct error messages with clear actions and treatment matched to the user's journey rather than a single notification style for every failure.

VA.gov Error and Alert Messages

VA.gov Design System - checked

VA documents error and alert messages as clear, direct content with a call to action that tells people what to do next.

Full agent/debug reference

Problem Context

  • A payment, save, permission, destructive action, security, or data-integrity operation fails.
  • The failed task still needs user action after the message appears.
  • The only visible feedback is a toast, snackbar, banner flash, or notification that may auto-dismiss or sit away from the affected control.
  • The product cannot guarantee the user saw, read, understood, and acted on the transient message before it disappeared.

Selection Rules

  • Flag this anti-pattern when a failure blocks progress, affects money or data, changes account or security state, or requires a repair action after the message appears.
  • Replace the toast-only treatment with a persistent inline, section-level, modal, or page-level error surface that names the failed task and keeps recovery controls visible.
  • Allow a toast for non-blocking confirmation, background status, or a supplemental announcement only when the same critical recovery remains reachable elsewhere.
  • For payment or save failures, keep the invoice, draft, form, or affected record visible and show a next action such as Retry, Update card, Edit details, Restore, or Contact support.
  • Do not auto-dismiss the only explanation for a failure that users may need to reference, report, copy, or act on later.

Required States

  • Pre-action state that shows what the user is attempting and what will be affected.
  • Failed persistent state with the failed object, plain-language cause, and recovery actions.
  • Supplemental notification state that does not replace the persistent failure surface.
  • Recovered state after retry, correction, reversal, or support escalation succeeds.
  • Still-failed state after a retry does not resolve the issue, with escalation or alternate path.

Interaction Contract

  • The critical error remains visible until it is resolved, intentionally dismissed from a safe persistent surface, replaced by a recovered state, or escalated.
  • The affected task stays connected to the recovery controls instead of making users search for the failed object after a notification disappears.
  • A toast may announce that failure happened, but it must not be the only place where the cause, consequence, support reference, or next action appears.
  • If the message auto-dismisses, users can still reach the same information and action from the failed task, notification center, activity log, or persistent error region.
  • Keyboard and assistive technology users can reach the recovery action without relying on timing, hover, or a temporary live-region announcement.

Implementation Checklist

  • Classify errors by consequence before choosing the feedback surface: low-risk status can be transient, but blocking, financial, destructive, permission, and data-loss failures need persistence.
  • Render the persistent error near the affected button, form, record, or page section and include the exact failed action in the heading.
  • Keep retry, correction, undo, support, or alternate-path actions visible and keyboard reachable after any toast closes.
  • Use a toast only as a duplicate announcement for urgent awareness, and link it to the persistent place where the user can recover.
  • Preserve entered data, selected items, payment context, and reference IDs so users can retry or ask for help without reconstructing the task.
  • Test the flow after the toast expires, with screen reader timing, reduced-motion settings, zoom, keyboard navigation, and delayed attention.

Common Generated-UI Mistakes

  • 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 disappearing snackbar as the only feedback for failed save, failed delete, failed permission change, failed upload, or failed authentication.
  • Placing the toast far from the failed form or table row so users cannot connect the message to the affected task.
  • Auto-dismissing a technical error code that support needs the user to copy or reference.
  • Replacing a contextual error state with a notification because it is easier to trigger from a global event handler.

Critique Questions

  • If the user looks away for five seconds, can they still tell what failed and what to do next?
  • Does the recovery action remain attached to the invoice, form, file, or account setting that failed?
  • Would a screen reader or keyboard user be able to act after the transient announcement has finished?
  • Is the toast communicating low-risk status, or is it carrying the only explanation for a high-consequence failure?
Accessibility
  • Do not rely on an auto-dismissing live-region announcement as the sole way to communicate a critical failure.
  • Place persistent error text and recovery controls in the reading order near the affected task.
  • Use alert or status semantics according to urgency, but pair the announcement with visible text that remains available.
  • Respect reduced-motion and timing needs by avoiding flows where users must chase a moving or disappearing notification.
  • Make retry, correction, undo, and support actions keyboard reachable after the notification is gone.
Keyboard Behavior
  • The recovery controls remain in the normal tab order after the toast closes.
  • Focus is not moved to a temporary toast unless the notification requires interaction and will persist long enough to use safely.
  • When retry starts, the persistent error surface exposes busy or progress state without removing the failed task context.
  • When recovery succeeds, focus moves to the recovered task status or a confirmation near the original control.
Variants
  • Toast-only payment failure
  • Snackbar-only save failure
  • Disappearing upload error
  • Transient permission denial
  • Toast-only destructive-action failure
  • Auto-dismissed support reference

Verification

Last verified: