Choose service unavailable page when the route exists but the service, transaction, or entry point is closed, under maintenance, overloaded, or temporarily unable to handle requests.
Choose service unavailable page when the route exists but the service, transaction, or entry point is closed, under maintenance, overloaded, or temporarily unable to handle requests.
Practice the judgment: Imagine this situation: A failed data load inside an existing route opens a 404 page, losing the user's filters, draft, and retry context. 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 | Page not found page | Service unavailable page | Error state | Empty state |
|---|---|---|---|---|
| UI or UX | UI + UX - Missing-route recovery page | UI + UX - Whole-service unavailable page | UI + UX - Recoverable failure surface | UI + UX - Resolved no-data content surface |
| UI guidance | Keep standard header and footer navigation when it helps orientation, but avoid breadcrumbs or path trails that imply the missing page has a valid hierarchy. | 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. | Keep surrounding context such as table title, filters, or workspace name visible so users know exactly what is empty. |
| UX guidance | Help the person reach a clear task outcome. | 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. | Move users toward the first useful object or prerequisite, and replace unavailable actions with permission or configuration guidance. |
| Good UI | The interface shows a clear action and state. | 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. | Permission variant explains that projects exist only after an admin grants access and offers Request access instead of Create. |
| Bad UI | A bare 404 code with a single Home button. | A blank white page with only 503 in the browser title. | Tiny transient toast for a blocking failure. | Oversized decorative art and vague welcome copy that hides the task. |
| Good UX | A user who mistyped a web address sees clear check-the-address advice and can search the service immediately. | 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. | Users can create the first project, import existing work, or request access depending on the actual cause. |
| Bad UX | A missing page is described as a service outage even though the rest of the service works. | Users miss a deadline because urgent offline support is omitted from the outage page. | Clearing work after save failure. | A primary Create button is shown to a read-only user and fails after activation. |
| Best fit | The team needs to measure and repair broken links. | Maintenance, overload, incident response, dependency failure, deployment, or permanent closure blocks normal use. | A system or task failure blocks expected content or action. | A next setup, creation, import, sample, or access-request action is available or explainable. |
| Avoid when | The service route exists but is temporarily closed, overloaded, or under maintenance. | Only one local section or action failed and users can recover inside the current page. | Nothing exists yet and the state is expected. | The absence was caused by filters or search. |
| Required state | Unknown route from typed or pasted URL. | Planned maintenance page with start or return time. | Normal expected state before failure. | First-use empty state before any objects exist. |
| Accessibility burden | Keep the explanation and recovery actions in logical reading order after the heading. | 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. | Keep the message in normal reading order near the empty region it explains. |
| Common misuse | Showing only a code, stack trace, route matcher name, or framework error. | Using a full-page spinner for a closed service. | Using a transient toast for critical errors. | Using marketing copy instead of a task-specific next step. |