Alert Banner vs Toast
A toast reports an event; a banner describes a condition. “Saved” happened once and is over — a toast. “Your card was declined” is still true right now, and will be true when the user comes back tomorrow — a banner. The mistake that costs the most is putting an actionable error in a toast: it removes itself after four seconds and takes the only explanation with it, leaving someone stuck with no way to read it again.
If missing it costs the user something, it must stay on screen. Toasts are for messages it is safe to miss.
Alert Banner
A persistent message placed in the page flow, describing a condition that remains true until something changes it.
Reach for it when
- A condition persists: payment failed, trial ending, service degraded, unsaved changes.
- The user must be able to re-read it. Anything containing an account number, a deadline or an instruction belongs here.
- There is an action attached, and the user should be able to reach it whenever they are ready.
- The message is tied to a place — a form, a section, a settings page — and belongs next to what it describes.
Avoid it when
- Confirming a completed action. “Saved” does not deserve permanent space; that is a toast.
- It appears on every page load. Banner blindness is real, and a banner that is always there stops being read within a week.
- Stacking several. Three banners above the content push the actual page below the fold and none of them get read.
- The message is about one field. Inline validation next to that field is more useful and easier to act on.
Toast
A brief message that appears over the interface, usually near an edge, and dismisses itself after a few seconds.
Reach for it when
- Confirming something the user just did, when the result is not visible on screen — saved, copied, sent, archived.
- Reporting that a background job finished while the user carried on with something else.
- Offering a short-lived undo. This is the one case where a toast may carry an action, and the timeout should be generous.
- The information is useful but losing it costs nothing.
Avoid it when
- Errors the user has to act on. A toast that vanishes takes the error message with it and leaves someone stuck.
- Form validation. The message belongs next to the field it is about, not floating in a corner.
- Anything longer than a sentence. Nobody finishes reading a paragraph before it fades.
- Critical or irreversible information. If it matters, it must stay on screen.
- Several at once. Stacked toasts turn into a wall nobody reads, and each one steals attention from the last.