toast

When to use

• Use toast for non-blocking acknowledgements of user-initiated actions, such as Domain added, Project archived, or Deployment canceled.
• Do not use a toast alone for billing failures, permission denials, or build failures that require investigation. Pair a short toast with a persistent recovery step and stable identifier.
• Keep field validation beside the Input; use a persistent Note or Banner for configuration warnings.

Behavior

• Toasts auto-dismiss by default. Pass preserve: true only when the user must read or act on the message before it disappears.
• Undo snackbars should stay visible for 5–10 seconds and pair a past-tense message with one Undo action. Use the onUndoAction option only when the rollback is safe.
• Do not stack toasts to narrate one asynchronous flow. Show one message at the terminal step instead.

Content

• Use one sentence, sentence case, and no trailing period for a single-sentence toast.
• Completion messages follow Noun + past participle: Blob deleted or Environment variable saved. Do not add successfully.
• Error messages use two sentences and end with a recovery step: Couldn't verify domain. Try again.. Use Couldn't for user-state errors and Failed to for system or infrastructure failures.
• Match the toast verb to the triggering action: Delete Project becomes Project deleted. Use the literal Undo label, not Restore or Bring Back.

Accessibility

• Keep the toast region aria-live="polite"; reserve assertive announcements for blocking errors that must interrupt the current flow.
• Keep action and dismiss controls keyboard reachable. Do not put primary navigation inside a toast because transient content can disappear before keyboard users reach it.