Back to compare picker

Site alert vs Banner vs Notification banner vs Alert

Use a site alert for urgent public or servicewide information across every page; use banner for scoped interface-wide messages, notification banner for a before-H1 page-flow notice, and alert for urgent current-task status.

Learn the decision

Match the interaction to the person's task

Use a site alert for urgent public or servicewide information across every page; use banner for scoped interface-wide messages, notification banner for a before-H1 page-flow notice, and alert for urgent current-task status.

Site alert

Use it when: Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service.

Make this state clear: Emergency site alert visible at the top of every affected page.

Observe the result: A user enters through a bookmarked application-status page and still sees the same closure alert before using the service.

Study the full pattern →

Banner

Use it when: The message applies across several pages, routes, sections, records, or sessions.

Make this state clear: Informational product or service banner at the top of the related interface.

Observe the result: A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace.

Study the full pattern →

Notification banner

Use it when: A service problem, deadline, overdue action, or elsewhere-in-service event affects the user's next interpretation of the page.

Make this state clear: Neutral Important state for service problem, deadline, overdue action, or elsewhere-in-service information.

Observe the result: A user lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey.

Study the full pattern →

Alert

Use it when: A current task has a time-sensitive warning, error, or important status change.

Make this state clear: Advisory or success state that uses calmer status semantics rather than assertive alert semantics.

Observe the result: When the connection returns, the alert downgrades to a success status and then can be dismissed safely.

Study the full pattern →

Practice the judgment: Imagine this situation: Three stacked site alerts push navigation and the page heading below the viewport. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Site alertBannerNotification bannerAlert
UI or UX UI + UX - Urgent full-width sitewide alert near the top of every pageUI + UX - Top-of-interface broad-scope messageUI + UX - Page-flow service notification before the H1UI + UX - Urgent current-task status message
UI guidance Render the site alert as a full-width message near the top of the site, before ordinary navigation or page content users might otherwise start from.Render the banner at the top of the interface or content area it governs, below required global chrome and before the page content that should be interpreted with that message.Render one notification banner in the page content column immediately before the page H1, using the same width as the surrounding service content.Render an alert as a visible message in the current task area with a clear severity cue, short title, consequence-focused body, and one direct action or safe dismissal when appropriate.
UX guidance Use a site alert when urgent public or servicewide information must be obvious and findable from any page, including deep links, refreshes, and routes outside the home page.Use banners when users need broad context before continuing across several pages or sections, such as maintenance, service delay, account setup, rollout, policy, or official-site identity information.Reserve the pattern for service-wide problems, personal deadlines or obligations elsewhere in the service, and outcomes from a previous page when the journey continues rather than ends.Use alerts when the user must notice a time-sensitive condition that affects their current task, such as session expiry, lost connection, unsaved work risk, failed submission, or a security-sensitive hold.
Good UI A public benefits site shows Emergency office closures at the very top of every page, with affected offices, updated time, and a link to alternate service channels.A billing workspace shows Scheduled maintenance Saturday directly below the product header across all billing pages, with View schedule and Dismiss when safe.A case-management page shows an Important notification banner immediately before Manage evidence, saying evidence upload may be delayed and linking to service status.A session alert appears above the active editor, says the session expires in 2 minutes, and offers Save draft while keeping the editor usable.
Bad UI Three large red alerts stack above the header, mixing closure, newsletter, and one form error.Three unrelated banners stack above the page heading and push the account task below the fold.A success toast appears in the corner after redirect and disappears before the user can verify which evidence was uploaded.Users miss an urgent condition because the message auto-expires or appears far from the affected task.
Good UX A user enters through a bookmarked application-status page and still sees the same closure alert before using the service.A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace.A user lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey.When the connection returns, the alert downgrades to a success status and then can be dismissed safely.
Bad UX Deep-linked users miss critical sitewide information because the alert exists only on the home page.A field validation error appears in a banner, forcing users to hunt for the failing input.The same upload confirmation remains on unrelated pages after the user has already reviewed the evidence record.The only warning that unsaved work will be lost disappears after five seconds.
Best fit Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service.The message applies across several pages, routes, sections, records, or sessions.A service problem, deadline, overdue action, or elsewhere-in-service event affects the user's next interpretation of the page.A current task has a time-sensitive warning, error, or important status change.
Avoid when The message applies only to one product workspace, account, section, page flow, field, row, or task.The message affects only one field, object, row, panel, or local task section.The message is a submitted-form validation error or field correction.The message belongs beside one object, row, field, or local section.
Required state Emergency site alert visible at the top of every affected page.Informational product or service banner at the top of the related interface.Neutral Important state for service problem, deadline, overdue action, or elsewhere-in-service information.Advisory or success state that uses calmer status semantics rather than assertive alert semantics.
Accessibility burden Give the site alert a descriptive aria-label or labelledby value so it appears clearly in landmark navigation.Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to.Use a labelled region for neutral page-load notification banners so screen-reader users can navigate to the notice.Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself.
Common misuse Showing a sitewide emergency only on the home page.Using a banner for one field error, one row warning, or one card status.Using a notification banner for field validation errors instead of an error summary and field-level messages.Using a disappearing toast for warnings users must act on before continuing.

Site alert

UI or UX
UI + UX - Urgent full-width sitewide alert near the top of every page
UI guidance
Render the site alert as a full-width message near the top of the site, before ordinary navigation or page content users might otherwise start from.
UX guidance
Use a site alert when urgent public or servicewide information must be obvious and findable from any page, including deep links, refreshes, and routes outside the home page.
Good UI
A public benefits site shows Emergency office closures at the very top of every page, with affected offices, updated time, and a link to alternate service channels.
Bad UI
Three large red alerts stack above the header, mixing closure, newsletter, and one form error.
Good UX
A user enters through a bookmarked application-status page and still sees the same closure alert before using the service.
Bad UX
Deep-linked users miss critical sitewide information because the alert exists only on the home page.
Best fit
Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service.
Avoid when
The message applies only to one product workspace, account, section, page flow, field, row, or task.
Required state
Emergency site alert visible at the top of every affected page.
Accessibility burden
Give the site alert a descriptive aria-label or labelledby value so it appears clearly in landmark navigation.
Common misuse
Showing a sitewide emergency only on the home page.

Banner

UI or UX
UI + UX - Top-of-interface broad-scope message
UI guidance
Render the banner at the top of the interface or content area it governs, below required global chrome and before the page content that should be interpreted with that message.
UX guidance
Use banners when users need broad context before continuing across several pages or sections, such as maintenance, service delay, account setup, rollout, policy, or official-site identity information.
Good UI
A billing workspace shows Scheduled maintenance Saturday directly below the product header across all billing pages, with View schedule and Dismiss when safe.
Bad UI
Three unrelated banners stack above the page heading and push the account task below the fold.
Good UX
A user moves from Overview to Invoices and still sees the same maintenance banner because the outage affects the whole billing workspace.
Bad UX
A field validation error appears in a banner, forcing users to hunt for the failing input.
Best fit
The message applies across several pages, routes, sections, records, or sessions.
Avoid when
The message affects only one field, object, row, panel, or local task section.
Required state
Informational product or service banner at the top of the related interface.
Accessibility burden
Use a labelled region or landmark when the banner is persistent page content that users may want to navigate to.
Common misuse
Using a banner for one field error, one row warning, or one card status.

Notification banner

UI or UX
UI + UX - Page-flow service notification before the H1
UI guidance
Render one notification banner in the page content column immediately before the page H1, using the same width as the surrounding service content.
UX guidance
Reserve the pattern for service-wide problems, personal deadlines or obligations elsewhere in the service, and outcomes from a previous page when the journey continues rather than ends.
Good UI
A case-management page shows an Important notification banner immediately before Manage evidence, saying evidence upload may be delayed and linking to service status.
Bad UI
A success toast appears in the corner after redirect and disappears before the user can verify which evidence was uploaded.
Good UX
A user lands on Evidence overview and sees the upload confirmation before the page heading, then can continue the unfinished service journey.
Bad UX
The same upload confirmation remains on unrelated pages after the user has already reviewed the evidence record.
Best fit
A service problem, deadline, overdue action, or elsewhere-in-service event affects the user's next interpretation of the page.
Avoid when
The message is a submitted-form validation error or field correction.
Required state
Neutral Important state for service problem, deadline, overdue action, or elsewhere-in-service information.
Accessibility burden
Use a labelled region for neutral page-load notification banners so screen-reader users can navigate to the notice.
Common misuse
Using a notification banner for field validation errors instead of an error summary and field-level messages.

Alert

UI or UX
UI + UX - Urgent current-task status message
UI guidance
Render an alert as a visible message in the current task area with a clear severity cue, short title, consequence-focused body, and one direct action or safe dismissal when appropriate.
UX guidance
Use alerts when the user must notice a time-sensitive condition that affects their current task, such as session expiry, lost connection, unsaved work risk, failed submission, or a security-sensitive hold.
Good UI
A session alert appears above the active editor, says the session expires in 2 minutes, and offers Save draft while keeping the editor usable.
Bad UI
Users miss an urgent condition because the message auto-expires or appears far from the affected task.
Good UX
When the connection returns, the alert downgrades to a success status and then can be dismissed safely.
Bad UX
The only warning that unsaved work will be lost disappears after five seconds.
Best fit
A current task has a time-sensitive warning, error, or important status change.
Avoid when
The message belongs beside one object, row, field, or local section.
Required state
Advisory or success state that uses calmer status semantics rather than assertive alert semantics.
Accessibility burden
Use role alert for urgent dynamic text and avoid putting interactive controls inside the role-alert node itself.
Common misuse
Using a disappearing toast for warnings users must act on before continuing.
Decision rules
  • Choose site alert when urgent information must be visible near the top of every page on a public site or service, such as emergency closure, unavailable service, safety warning, or critical operating status.
  • Choose banner when the message is broad but scoped to a product, account, workspace, section, or official identity treatment rather than the whole site.
  • Choose notification banner when the message belongs in one page's content flow immediately before the H1, such as a previous-page outcome, personal deadline, or service notice tied to that page journey.
  • Choose alert when a time-sensitive condition dynamically affects the user's current task and needs immediate notice without becoming a global sitewide announcement.
  • Use a single site alert with a short list of related links when multiple urgent sitewide messages compete; do not stack several top-of-site alerts.
  • Do not use site alert for submitted form validation, task success, one-field correction, row status, or local workflow feedback; those belong in error summary, alert, inline message, or notification banner.
  • Use emergency site-alert treatment only for genuinely urgent public or servicewide risk; routine outages or informational notices may need calmer site-alert styling or a scoped banner.
  • Allow dismissal only when the message is noncritical or recoverable elsewhere, and version dismissal by alert id and update so new emergency content reappears.
Inspect live examples
Failure modes
  • A sitewide emergency closure is shown only on the home page, so deep-linked users never see it.
  • Three stacked site alerts push navigation and the page heading below the viewport.
  • A form validation error is promoted to a site alert and appears on unrelated pages.
  • A workspace-only rollout notice is shown as a public site alert and alarms users outside the affected audience.
  • A dynamic evacuation update changes silently because no role or status announcement is used.
  • A critical alert can be dismissed permanently with no versioning, so users miss later emergency updates.

Saved items