Overview

Toasts confirm — they don't ask. Use them for "Workspace saved", "5 records imported", "Failed to upload". Never use a toast for a question or a blocking decision; that's a modal action set. Stack vertically when multiple toasts fire in sequence, newest on top.

Use cases

  • Successful actions. Confirm a save, upload, delete, or other reversible operation that completed.
  • Non-blocking errors. Tell the user something failed but they can keep working ("Network error, retry in 5s").
  • Background completions. An import or export finished; the user wasn't waiting for it.
  • Undo flows. Pair "Deleted Q3 Planning" with an "Undo" action button inside the toast.

Properties

ElementClassNotes
Toast shell.toastWhite surface, soft-2 shadow, 8 px radius, 12/16 px padding, 320 px width.
Status icon.toast-icon20 px icon with semantic color (green for success, red for error, blue for info).
Variant.toast.success · .toast.error · .toast.infoSets icon color and the 3 px left rail tint.
Action button.toast-actionOptional in-toast button — typically "Undo" or "View".
Close.toast-closeX button to dismiss before auto-timer expires.

Best practices

  • Use sparingly. A toast every minute = noise. Reserve for state changes the user genuinely needs to know about.
  • One sentence. Toasts read in passing. If a user needs to actually read 2+ lines, switch to a banner or modal.
  • Action button max 1. "Undo" or "View". More than one means the toast is doing too much.
  • 4 s default, 8 s with action. Give the user enough time to read and click an Undo if present.
  • Errors don't auto-dismiss. Critical errors stay until the user dismisses or retries.