What the person is doing
Users may arrive from bookmarks, notifications, search results, saved tasks, payment links, or forms already in progress.
Application · lesson 22 of 30 · Feedback, Status, And System State
Service unavailable page
Underlying principle: Status connects an action to a real system event. A useful message names the current state, its consequence, and the next available action.
Show a durable service unavailable page that identifies the affected service, explains planned or unexpected unavailability, gives recovery timing or update cadence, states saved-work impact, provides alternate or urgent routes, and avoids implying active progress when the service is closed.
Study the interaction
Follow the task before choosing the component
Status connects an action to a real system event. A useful message names the current state, its consequence, and the next available action.
What the interface must communicate
Show a durable service unavailable page that identifies the affected service, explains planned or unexpected unavailability, gives recovery timing or update cadence, states saved-work impact, provides alternate or urgent routes, and avoids implying active progress when the service is closed.
Planned maintenance page with start or return time.
What to look for
Which service, route, or transaction is unavailable?
The page replaces the affected service route until the service can safely handle requests again.
Decision first
Choose this pattern when the problem matches
Use when
- Maintenance, overload, incident response, dependency failure, deployment, or permanent closure blocks normal use.
- Users need a durable page that explains timing, saved-work impact, and alternate routes.
- The response needs to align user-facing recovery with operational status such as 503, Retry-After, incident reference, or maintenance notice.
Avoid when
- Only one local section or action failed and users can recover inside the current page.
- The user's own device is offline and the product can show cached work or reconnect behavior.
- A notice is only warning users about a future outage while the service remains usable.
- The service is loading normally and a short spinner, skeleton, or progress indicator is enough.
Problem it prevents
Users may arrive from bookmarks, notifications, search results, saved tasks, payment links, or forms already in progress.
Test the behavior
Open the interactive example when you need it
The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.
In the lab you can
Launch Service unavailable page in the lab - switch between strong UI, weak UI, strong UX, and weak UX;
- trigger required, empty, loading, error, and recovery states;
- inspect keyboard and accessibility expectations beside the demo.
Pattern anatomy
What a strong implementation has to make clear
Users may arrive from bookmarks, notifications, search results, saved tasks, payment links, or forms already in progress.
Show a durable service unavailable page that identifies the affected service, explains planned or unexpected unavailability, gives recovery timing or update cadence, states saved-work impact, provides alternate or urgent routes, and avoids implying active progress when the service is closed.
Planned maintenance page with start or return time.
Browser or proxy caches the outage page after the service recovers.
Keep the explanation in normal reading order with clear paragraphs and links that describe the destination.
Quality bar
The difference between expert and weak execution
Strong implementation
Specific, visible, recoverable
- 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 closed legacy service page explains that the old report submission service has closed permanently and links to the replacement service and support contact.
- 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.
- A user follows an old transaction link, learns the service closed permanently, and moves to the replacement route instead of contacting support blindly.
Weak implementation
Vague, hidden, hard to recover from
- A blank white page with only 503 in the browser title.
- A full-page spinner implies progress even though the service has been deliberately closed for maintenance.
- Users miss a deadline because urgent offline support is omitted from the outage page.
- Browser or proxy caches the outage page after the service recovers.
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.
- Use plain page content rather than spinners, progress bars, modal dialogs, or stacked alerts when the service entry point itself cannot be used.
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.
- Tell users what happened, what they can still do, what happens to their work, when to come back, and how to handle urgent or time-sensitive tasks.
Implementation contract
What the implementation must handle
States
- Planned maintenance page with start or return time.
- Unexpected outage page with status update or request ID.
- Overload page with retry-after guidance.
- Saved draft state that says answers are retained and for how long.
Interaction
- The page replaces the affected service route until the service can safely handle requests again.
- The HTTP response, cache headers, page title, visible heading, and user copy agree that the condition is temporary or permanently closed.
- Retry and refresh actions are labeled according to safety: reload page, check status, continue saved draft, start again, or contact support.
- If the unavailable state interrupts a transaction, the page states whether answers, payment, upload, booking, or submission state was preserved.
Accessibility
- Keep the explanation in normal reading order with clear paragraphs and links that describe the destination.
- Move focus to the page heading after redirecting from a failed route or blocked transaction.
- Expose status updates, last-updated time, and saved-work messages as text rather than only in visual badges.
- Ensure contact links, status links, replacement routes, and start-again actions are keyboard reachable and have explicit names.
Review
- Which service, route, or transaction is unavailable?
- Is the outage planned, unexpected, partial, overloaded, or permanent?
- When should users come back, or when will the next update be posted?
- What happened to in-progress answers, payments, uploads, or bookings?
Evidence trail
Source-backed claims behind this guidance
GOV.UK service unavailable pages
GOV.UK Design System - checked
GOV.UK documents service unavailable page copy for planned closure, return time, saved answers, permanent closure, replacement service, and support contact.
MDN HTTP 503 Service Unavailable
MDN Web Docs - checked
MDN documents 503 temporary unavailability, maintenance and overload causes, Retry-After timing, user-friendly pages, request IDs, and cache caution.
ONS error and status pages
Office for National Statistics Service Manual - checked
ONS documents unexpected service-problem pages, saved answers, contact routes, short-duration display, logging, and maintenance notice escalation.
MOJ outage banner
MOJ Design System - checked
MOJ documents pre-outage banners for scheduled whole-platform or service outages and helps distinguish advance notice from unavailable-page treatment.
Full agent/debug reference
Problem Context
- The service has scheduled maintenance, emergency shutdown, traffic overload, deployment, dependency outage, permanent closure, or an entry route that cannot handle requests.
- Users may arrive from bookmarks, notifications, search results, saved tasks, payment links, or forms already in progress.
- The unavailable state may affect the whole service, one transaction, one region, one identity provider, one payment route, or a permanent legacy endpoint.
- The product needs to coordinate HTTP status, service page copy, incident communication, saved drafts, support channels, and cache behavior.
Selection Rules
- Choose service unavailable page when the user cannot proceed because the service entry point, transaction, or route is closed or server-side capacity is unavailable.
- Use planned-outage copy when the closure is scheduled and the return time, start time, or window is known.
- Use unexpected-outage copy when the service is failing now; include request ID, status page, support route, and update cadence when available.
- State saved-work impact: saved answers, unsaved answers, draft retention, duplicate-submission safety, payment status, or start-again requirement.
- Give urgent alternatives for benefits, health, payments, legal duties, statutory reporting, travel, identity, or deadline-sensitive tasks.
- Use permanent-closure copy when a service is retired; link to replacement service, archived guidance, phone route, or contact path.
- Use error state when only a component, query, upload, or save failed while the surrounding service remains usable.
- Use offline state when the user's connection is the primary problem and local cached work or reconnect behavior is available.
- Use site alert or banner to announce upcoming or partial outages while users can still navigate or complete allowed tasks.
- Avoid automatic refresh loops unless they are rate-limited, announced, and do not duplicate submissions or obscure the recovery time.
Required States
- Planned maintenance page with start or return time.
- Unexpected outage page with status update or request ID.
- Overload page with retry-after guidance.
- Saved draft state that says answers are retained and for how long.
- Unsaved work state that says users must start again.
- Partial outage state that says which task is unavailable and which tasks still work.
- Urgent alternate channel state.
- Permanent closure or replacement-service state.
- Status-page or incident-update link state.
- Post-recovery handoff state that avoids duplicate submission.
Interaction Contract
- The page replaces the affected service route until the service can safely handle requests again.
- The HTTP response, cache headers, page title, visible heading, and user copy agree that the condition is temporary or permanently closed.
- Users can reach support, status updates, allowed alternate services, or a safe exit without returning through broken navigation.
- Retry and refresh actions are labeled according to safety: reload page, check status, continue saved draft, start again, or contact support.
- If the unavailable state interrupts a transaction, the page states whether answers, payment, upload, booking, or submission state was preserved.
Implementation Checklist
- Route planned maintenance, overload, unexpected incident, permanent closure, and partial dependency failures to distinct copy variants.
- Set the correct server status for temporary unavailability and configure Retry-After or equivalent recovery timing where possible.
- Prevent caching of temporary outage pages in ways that keep users on stale unavailable content after recovery.
- Include service identity, incident or request ID, support link, status page, saved-work status, and last-updated time when available.
- Provide operational controls to update return time, maintenance window, support contact, replacement service, and saved-work copy without redeploying the application.
- Test bookmarks, deep links, form-in-progress sessions, payment retries, duplicate submissions, mobile widths, screen readers, and post-recovery transitions.
Common Generated-UI Mistakes
- Using a full-page spinner for a closed service.
- Showing only 503 or Something went wrong without service scope, return time, or support route.
- Sending users to a homepage with no explanation of the outage.
- Promising saved work without checking transaction state.
- Telling users to retry immediately when the service is deliberately closed.
- Using a site alert after the affected transaction can no longer be used.
Critique Questions
- Which service, route, or transaction is unavailable?
- Is the outage planned, unexpected, partial, overloaded, or permanent?
- When should users come back, or when will the next update be posted?
- What happened to in-progress answers, payments, uploads, or bookings?
- What urgent or offline route exists for users with deadlines?
- Does retrying create duplicate submissions, payments, or support tickets?
Accessibility
- Use a unique page title and H1 that state the service is unavailable, not just a code.
- Keep the explanation in normal reading order with clear paragraphs and links that describe the destination.
- Do not rely on color, icons, animations, or progress movement to communicate outage state.
- Move focus to the page heading after redirecting from a failed route or blocked transaction.
- Expose status updates, last-updated time, and saved-work messages as text rather than only in visual badges.
- Ensure contact links, status links, replacement routes, and start-again actions are keyboard reachable and have explicit names.
Keyboard Behavior
- Focus lands on the service unavailable heading when the page loads.
- Tab order moves from explanation to status update, alternate service, contact path, safe retry, and exit links.
- If a saved draft can be continued after recovery, the Continue saved draft action returns focus to the correct form step.
- If start-again is required, confirmation or copy must explain lost work before routing users away.
- Do not trap focus in a maintenance overlay or modal when the whole page is the state.
- Auto-refresh, if present, must not steal focus or repeatedly announce the full page.
Variants
- Planned maintenance
- Unexpected outage
- Overload
- Retry-after page
- Saved answers unavailable page
- Unsaved answers unavailable page
- Partial service outage
- Urgent support fallback
- Permanent closure
- Replacement service handoff
- Status page handoff
Verification
Source trail checked: