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 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.
Practice the judgment: Imagine this situation: A 503 page says only Service unavailable and leaves users unsure whether to retry now, later today, tomorrow, or by another channel. 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 →| 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. | Match the next action to the failure cause: retry transient failures, edit correctable input, use cached fallback for read-only continuity, or provide support reference when recovery is outside the UI. | 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. | A failed save state keeps the draft visible and labels the support reference separately from the user-facing explanation. | 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. | Three large red alerts stack above the header, mixing closure, newsletter, and one form error. |
| 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 miss a deadline because urgent offline support is omitted from the outage page. | Clearing work after save failure. | A submitted offline form disappears from the screen even though it was neither queued nor accepted by the server. | Deep-linked users miss critical sitewide information because the alert exists only on the home page. |
| Best fit | Maintenance, overload, incident response, dependency failure, deployment, or permanent closure blocks normal use. | 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. | Offline banner or local status that names affected scope. | Emergency site alert visible at the top of every affected page. |
| Accessibility burden | Keep the explanation in normal reading order with clear paragraphs and links that describe the destination. | 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. |