Service unavailable page vs Error state vs Offline state vs Site alert

Choose service unavailable page when users cannot use the service entry point, transaction, account area, or route because the service is intentionally closed, under maintenance, overloaded, shuttered, or temporarily not ready to handle requests.

Service unavailable page live example Error state live example Offline state live example Site alert live example

Decision dimensions

Dimension	Service unavailable page	Error state	Offline state	Site alert
UI or UX	UI + UX - Whole-service unavailable page	UI + UX - Recoverable failure surface	UI + UX - Connectivity-mode and local-work continuity state	UI + UX - Urgent full-width sitewide alert near the top of every page
UI guidance	Render a full page with the service name, unavailable scope, status, return time or update promise, saved-work status, alternate route, support contact, and request or incident reference when available.	Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.	Show offline status where it changes the current task, naming what remains available such as cached reports, local draft editing, queued saves, or read-only history.	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 service unavailable page when the service, transaction, or route is intentionally closed, under maintenance, overloaded, permanently closed, or unable to handle requests at the entry point.	Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.	Use offline state to preserve trust and task continuity when connection loss changes what users can read, edit, submit, sync, refresh, or share.	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 benefits application page says the service is unavailable from 22:00 to 01:00, names the affected transaction, says saved drafts remain for 30 days, and links to urgent phone support.	Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.	A field report says Offline: 3 edits saved on this device, cached customer history shown from 10:42, Submit disabled until connection returns, and Retry connection.	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	A blank white page with only 503 in the browser title.	Tiny transient toast for a blocking failure.	A blank page says You are offline even though the app has cached drafts and help content.	The emergency message appears only on the home page, so users who land on Apply or Help do not see it.
Good UX	A user returns during planned maintenance, sees a precise reopening time, learns their draft is saved, and uses an alternate phone channel for an urgent deadline.	User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.	A user loses connection while editing an inspection note, sees it saved on this device, attaches photos to a queue, and later watches the queue sync after reconnect.	A user enters through a bookmarked application-status page and still sees the same closure alert before using the service.
Bad UX	Users repeatedly refresh because the page gives no recovery window or status update path.	Clearing work after save failure.	The app keeps a spinner on Save during airplane mode and never explains that no network request can start.	Users dismiss a critical emergency alert once and never see a later update because dismissal is not versioned.
Best fit	A whole service, transaction entry point, or route is closed or not ready to handle requests.	A system or task failure blocks expected content or action.	Connection loss or server reachability changes the user's current task.	Urgent public, safety, operating-status, outage, closure, or availability information applies to the whole site or service.
Avoid when	Only one local section or action failed and users can recover inside the current page.	Nothing exists yet and the state is expected.	A single request failed while the rest of the app is reachable and an error state is clearer.	The message applies only to one product workspace, account, section, page flow, field, row, or task.
Required state	Planned maintenance page with start or return time.	Normal expected state before failure.	Online normal state with no offline warning.	No-site-alert state when no urgent sitewide condition applies.
Accessibility burden	Use a unique page title and H1 that state the service is unavailable, not just a code.	Use appropriate alert or status semantics for newly appearing critical errors.	Announce significant connectivity changes with status messaging when they affect the current task.	Give the site alert a descriptive aria-label or labelledby value so it appears clearly in landmark navigation.
Common misuse	Using a full-page spinner for a closed service.	Using a transient toast for critical errors.	Showing only a browser-style offline page when useful cached or local content exists.	Showing a sitewide emergency only on the home page.

Service unavailable page

UI or UX: UI + UX - Whole-service unavailable page
UI guidance: Render a full page with the service name, unavailable scope, status, return time or update promise, saved-work status, alternate route, support contact, and request or incident reference when available.
UX guidance: Use a service unavailable page when the service, transaction, or route is intentionally closed, under maintenance, overloaded, permanently closed, or unable to handle requests at the entry point.
Good UI: A benefits application page says the service is unavailable from 22:00 to 01:00, names the affected transaction, says saved drafts remain for 30 days, and links to urgent phone support.
Bad UI: A blank white page with only 503 in the browser title.
Good UX: A user returns during planned maintenance, sees a precise reopening time, learns their draft is saved, and uses an alternate phone channel for an urgent deadline.
Bad UX: Users repeatedly refresh because the page gives no recovery window or status update path.
Best fit: A whole service, transaction entry point, or route is closed or not ready to handle requests.
Avoid when: Only one local section or action failed and users can recover inside the current page.
Required state: Planned maintenance page with start or return time.
Accessibility burden: Use a unique page title and H1 that state the service is unavailable, not just a code.
Common misuse: Using a full-page spinner for a closed service.

Error state

UI or UX: UI + UX - Recoverable failure surface
UI guidance: Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.
UX guidance: Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.
Good UI: Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.
Bad UI: Tiny transient toast for a blocking failure.
Good UX: User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.
Bad UX: Clearing work after save failure.
Best fit: A system or task failure blocks expected content or action.
Avoid when: Nothing exists yet and the state is expected.
Required state: Normal expected state before failure.
Accessibility burden: Use appropriate alert or status semantics for newly appearing critical errors.
Common misuse: Using a transient toast for critical errors.

Offline state

UI or UX: UI + UX - Connectivity-mode and local-work continuity state
UI guidance: Show offline status where it changes the current task, naming what remains available such as cached reports, local draft editing, queued saves, or read-only history.
UX guidance: Use offline state to preserve trust and task continuity when connection loss changes what users can read, edit, submit, sync, refresh, or share.
Good UI: A field report says Offline: 3 edits saved on this device, cached customer history shown from 10:42, Submit disabled until connection returns, and Retry connection.
Bad UI: A blank page says You are offline even though the app has cached drafts and help content.
Good UX: A user loses connection while editing an inspection note, sees it saved on this device, attaches photos to a queue, and later watches the queue sync after reconnect.
Bad UX: The app keeps a spinner on Save during airplane mode and never explains that no network request can start.
Best fit: Connection loss or server reachability changes the user's current task.
Avoid when: A single request failed while the rest of the app is reachable and an error state is clearer.
Required state: Online normal state with no offline warning.
Accessibility burden: Announce significant connectivity changes with status messaging when they affect the current task.
Common misuse: Showing only a browser-style offline page when useful cached or local content exists.

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: The emergency message appears only on the home page, so users who land on Apply or Help do not see it.
Good UX: A user enters through a bookmarked application-status page and still sees the same closure alert before using the service.
Bad UX: Users dismiss a critical emergency alert once and never see a later update because dismissal is not versioned.
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: No-site-alert state when no urgent sitewide condition applies.
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.

Decision rules

Choose service unavailable page when users cannot use the service entry point, transaction, account area, or route because the service is intentionally closed, under maintenance, overloaded, shuttered, or temporarily not ready to handle requests.
Choose error state when a specific section, query, save, upload, payment, or resource operation failed but the surrounding service shell remains available and recovery can happen in place.
Choose offline state when the user's device or browser lacks network connectivity but cached content, local work, queue status, or reconnect behavior can still be explained inside the product.
Choose site alert when users should be warned before, during, or after a broad incident while they can still navigate or complete some tasks; escalate to service unavailable page once the affected service cannot be used.
A service unavailable page must name the service, the unavailable scope, whether the outage is planned, unexpected, partial, or permanent, and when or how users should return when that is known.
Include saved-work status for interrupted transactions: saved answers, unsaved answers, session expiry, retry safety, and what users must redo after the service returns.
Provide alternate channels when the service supports urgent needs, statutory deadlines, payments, health, benefits, reporting, or time-limited tasks.
Do not use a progress bar, loading spinner, or auto-refresh loop for a service that is closed; those imply active progress rather than an unavailable service state.

Inspect live examples

Service unavailable page Error state Offline state Site alert

Failure modes

A 503 page says only Service unavailable and leaves users unsure whether to retry now, later today, tomorrow, or by another channel.
A scoped failed save opens a full service-unavailable page even though only one form submission failed and the rest of the service is usable.
A device offline state is mislabeled as service unavailable, so users blame the service instead of reconnecting or using cached work.
A scheduled outage remains as a small site alert after the transaction entry point is already closed, so users keep trying blocked paths.
A page claims work is saved but does not distinguish saved answers, unsaved answers, or how long saved work is retained.
A permanent closure does not link to the replacement service, phone route, or support contact.