What the person is doing
A payment, save, permission, destructive action, security, or data-integrity operation fails.
Quality check · lesson 30 of 30 · Feedback, Status, And System State
Toast-only critical error
Underlying principle: Status connects an action to a real system event. A useful message names the current state, its consequence, and the next available action.
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.
Study the interaction
Follow the task before choosing the component
Status connects an action to a real system event. A useful message names the current state, its consequence, and the next available action.
What the interface must communicate
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.
Pre-action state that shows what the user is attempting and what will be affected.
What to look for
If the user looks away for five seconds, can they still tell what failed and what to do next?
The critical error remains visible until it is resolved, intentionally dismissed from a safe persistent surface, replaced by a recovered state, or escalated.
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
- A toast supplements a persistent error state, inline validation message, undo affordance, or notification center item that users can revisit.
Problem it prevents
A payment, save, permission, destructive action, security, or data-integrity operation fails.
Test the behavior
Open the interactive example when you need it
The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.
In the lab you can
Launch Toast-only critical error in the lab - switch between strong UI, weak UI, strong UX, and weak UX;
- trigger required, empty, loading, error, and recovery states;
- inspect keyboard and accessibility expectations beside the demo.
Pattern anatomy
What a strong implementation has to make clear
A payment, save, permission, destructive action, security, or data-integrity operation fails.
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.
Pre-action state that shows what the user is attempting and what will be affected.
The user misses the only error message and repeats the failed action.
Place persistent error text and recovery controls in the reading order near the affected task.
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
- Users have to guess whether the payment, save, delete, or upload succeeded after the toast timed out.
- The user misses the only error message and repeats the failed action.
- The page appears normal after a critical operation failed, so users trust an unsafe or incomplete state.
- A support reference disappears before the user can copy it.
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.
- 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.
- 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
- 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.
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?
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
Source trail checked: