Skip to content

Alert

An in-page message about something needing attention — persistent, placed where it applies, and dismissed only when resolved.

UI Components

An alert is an in-page message about something needing attention. It stays until the condition is resolved, and it sits where the condition applies.

That persistence is what distinguishes it from a toast. A toast reports an event and leaves; an alert describes a problem that is still true. Reporting a failed payment in a toast means telling the one person who happened to be looking at that corner for five seconds.

Placement carries half the meaning

Field-level for anything about a single input — beside the field, not in a summary at the top of a long form that makes somebody hunt.

Section-level for anything about a region: a table that failed to load, a panel whose data is stale.

Page-level for anything about the record or screen as a whole.

Global, as a banner, for anything affecting the whole account: an expired card, a degraded integration, a plan limit reached.

The further an alert sits from its cause, the more work it hands the reader. A page-level message about a field is a puzzle.

Writing one

Three things in order: what happened, what it means, what to do.

We could not reach your billing provider. Your data is safe and nothing was charged. Try again, or contact support if it keeps happening.

Against the version products usually ship:

Error 4021

The second tells somebody that something is wrong and gives them nothing to do about it, which produces a support ticket in place of a retry.

Say what is safe. In error states people's first question is what they lost. Answering it unprompted removes most of the anxiety.

Avoid blame. "You entered an invalid date" and "This date format is not recognised — try DD/MM/YYYY" describe the same event and read very differently.

Give the action as a control, not as an instruction to go and find one.

Severity, and why colour is not enough

Three or four levels: informational, warning, error, and sometimes success. Beyond that nobody distinguishes them.

Each needs a treatment that survives without colour — an icon, a border weight, a label. Colour alone excludes anybody who cannot distinguish the palette, and it disappears entirely in a screenshot pasted into a support ticket, which is how a great many of these messages are actually read.

Dismissal

Dismissible only if dismissing resolves it. A message about an expired card that can be closed will be closed, and then the product refuses payments for the rest of the session with nothing on screen explaining why.

Never auto-dismiss an error. The message somebody most needed, gone in five seconds.

Return, if the condition returns. An alert dismissed on Monday for a condition that recurs on Tuesday should reappear rather than staying quiet because it was once acknowledged.

In B2B specifically

Partial failures need a route. "6 of 40 records failed" is only useful with a way to reach the six. See bulk actions.

Permission alerts should say who can help. A member blocked by permissions needs to know which role can grant access, not simply that they cannot proceed.

Billing and limit alerts belong to the account, not the user. A message only the admin sees about a limit everybody is hitting produces four confused people and one who can act.

Announce them. An alert appearing after an action needs a live region, or it is invisible to a screen reader — and error alerts specifically should be assertive rather than polite.

In practice

A form validates on submit and shows a summary of errors at the top of the page.

On a short form it is fine. On the fourteen-field configuration form, somebody submits, the page scrolls to the top, and they are told three fields have problems — without being told which. They then scroll through fourteen fields looking for red.

Moving the messages beside their fields ends that entirely, and keeps the summary as a count with links. Same validation, same copy, and the work of locating the problem moves from the person to the interface.

Where teams get it wrong

  • A toast for a lasting problem. Seen once, by whoever was looking.
  • A summary far from the fields. The reader does the searching.
  • Error codes. Information with no action attached.
  • Dismissible for something still true. Closed, forgotten, then inexplicable.
  • Colour as the only severity signal. Lost on a screenshot and on a real share of users.
  • No live region. Silent for anybody not watching that part of the screen.

Frequently Asked Questions