Toast notification vs Toast-only critical error vs Error state vs Undo

Choose toast notification when the user has just completed a low-risk action, background work changed state, or a short status update is useful without blocking the current task.

Toast notification live example Toast-only critical error live example Error state live example Undo live example

Decision dimensions

Dimension	Toast notification	Toast-only critical error	Error state	Undo
UI or UX	UI + UX - Transient non-modal status message	UI + UX - Transient critical-feedback anti-pattern	UI + UX - Recoverable failure surface	UX - Post-action recovery behavior
UI guidance	Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action.	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.	Show a named recovery affordance after the completed action, such as Undo delete for a specific task, near the result or in a consistent status region.
UX guidance	Use toast notifications for low-risk, short-lived feedback after an action completes or background work changes state without requiring the user to stop the current task.	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.	Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result.
Good UI	Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history.	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.	Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button.
Bad UI	Five unrelated toasts pile up over the Save and Continue controls.	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.	A tiny x removes an item with no object-specific recovery label.
Good UX	A completed archive action shows a short toast and a specific Undo action because the prior state can be restored.	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.	Undo restores the deleted task to the list and reports Quarterly report restored.
Bad UX	Every autosave tick triggers a toast, training users to ignore real status changes.	Users have to guess whether the payment, save, delete, or upload succeeded after the toast timed out.	Clearing work after save failure.	A second delete overwrites the first recoverable item without explaining which action Undo affects.
Best fit	Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export.	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.	The action is common and mistakes are likely.
Avoid when	The message is the only recovery path for a blocking or high-consequence failure.	The message is a low-risk confirmation and no follow-up action is required.	Nothing exists yet and the state is expected.	The action has external side effects that cannot be recalled.
Required state	Idle state with no visible toast and a reachable status or history region when applicable.	Pre-action state that shows what the user is attempting and what will be affected.	Normal expected state before failure.	Normal state before the user action.
Accessibility burden	Expose the toast as a status or alert message according to urgency so assistive technologies can announce it without requiring focus movement.	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.	Make the undo control keyboard reachable and programmatically identifiable.
Common misuse	Using a toast as the only feedback for payment, save, permission, upload, or security failures.	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.	Offering undo for an action that cannot actually be reversed.

Toast notification

UI or UX: UI + UX - Transient non-modal status message
UI guidance: Render toast notifications in a consistent non-modal region with short status text, clear severity, an optional close control, and at most one concise action.
UX guidance: Use toast notifications for low-risk, short-lived feedback after an action completes or background work changes state without requiring the user to stop the current task.
Good UI: Export started appears in the top notification region with a timestamp, close control, and View jobs action that remains available in activity history.
Bad UI: Five unrelated toasts pile up over the Save and Continue controls.
Good UX: A completed archive action shows a short toast and a specific Undo action because the prior state can be restored.
Bad UX: Every autosave tick triggers a toast, training users to ignore real status changes.
Best fit: Use for short non-blocking confirmation after explicit actions such as save, copy, send, archive, invite, or queue export.
Avoid when: The message is the only recovery path for a blocking or high-consequence failure.
Required state: Idle state with no visible toast and a reachable status or history region when applicable.
Accessibility burden: Expose the toast as a status or alert message according to urgency so assistive technologies can announce it without requiring focus movement.
Common misuse: Using a toast as the only feedback for payment, save, permission, upload, or security failures.

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.

Undo

UI or UX: UX - Post-action recovery behavior
UI guidance: Show a named recovery affordance after the completed action, such as Undo delete for a specific task, near the result or in a consistent status region.
UX guidance: Let users move quickly through frequent reversible actions, then recover from mistakes after seeing the result.
Good UI: Deleting Quarterly report removes it from the list and shows a recovery panel saying Quarterly report deleted with an Undo task button.
Bad UI: A tiny x removes an item with no object-specific recovery label.
Good UX: Undo restores the deleted task to the list and reports Quarterly report restored.
Bad UX: A second delete overwrites the first recoverable item without explaining which action Undo affects.
Best fit: The action is common and mistakes are likely.
Avoid when: The action has external side effects that cannot be recalled.
Required state: Normal state before the user action.
Accessibility burden: Make the undo control keyboard reachable and programmatically identifiable.
Common misuse: Offering undo for an action that cannot actually be reversed.

Decision rules

Choose toast notification when the user has just completed a low-risk action, background work changed state, or a short status update is useful without blocking the current task.
Choose error state when the message names a failed load, save, payment, permission, upload, or destructive operation that users must inspect or repair after the moment passes.
Choose undo when the product can restore the exact prior state of a completed reversible action and the toast or snackbar is carrying a specific recovery control.
Flag toast-only critical error when the disappearing message is the only place that explains failure consequence, support reference, retry path, or unpaid/unsaved state.
Use a notification center, activity log, or inline status when users may need to revisit the message after auto-dismissal, such as export-ready, approval-required, or compliance notices.
Limit toast actions to one short contextual action such as Undo or View; move multi-step resolution, form correction, or support instructions into a persistent surface.
Do not stack unrelated toasts indefinitely; cap visible messages, preserve recency order, and avoid covering primary controls or assistive technology focus targets.
Announce toast status without stealing focus unless the toast contains an action that must be operated immediately and remains available long enough to use safely.

Inspect live examples

Toast notification Toast-only critical error Error state Undo

Failure modes

A save success toast appears for every keystroke and overwhelms the page with repeated confirmations.
A failed payment toast disappears and leaves no persistent invoice recovery path.
An Undo action vanishes before keyboard or screen reader users can reach it.
Several export-ready messages stack over the primary submit button and hide the current task.
The toast says Done without naming the object, action, or resulting state.
A long compliance notice is squeezed into a two-line toast instead of a durable message surface.