Back to compare picker

Graceful degradation vs Fallback path vs Offline state vs Service unavailable page

Use graceful degradation when the current page can still complete its core task after an enhancement layer fails, such as replacing a calendar widget with date fields, a map with a location list, or drag-and-drop with a file input.

Decision dimensions

Dimension Graceful degradationFallback pathOffline stateService unavailable page
UI or UX UI + UX - Reduced-capability same-surface experience that preserves the core taskUI + UX - User-directed alternate route when the primary path cannot completeUI + UX - Connectivity-mode and local-work continuity stateUI + UX - Whole-service unavailable page
UI guidance Show the baseline controls on the same surface as the failed enhancement: date fields behind a date picker, a location list behind a map, a file input behind drag-and-drop, readable content behind animation, and plain links behind scripted navigation.Place the alternate route beside the blocked primary path with a label that names what changes, such as Enter address manually, Use cached report, Call support with reference, or Continue with paper evidence.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 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 graceful degradation when a richer layer is unavailable but the user can still complete the core task with a simpler interaction on the current page.Use a fallback path when the primary route is unavailable, unsuitable, unsupported, or repeatedly failing, and users still need a credible way to complete the task.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 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 An appointment date picker says Calendar unavailable, keeps Day, Month, and Year fields with a format hint, and lets users continue after valid entry.An address lookup says We could not find this address, keeps postcode SW1A 1AA visible, and offers Enter address manually, Try another postcode, and Get help with reference APP-2048.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 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 failed calendar script leaves an empty rectangle and a disabled Continue button.A lookup returns No matches and only shows Search again, even though manual address entry is supported.A blank page says You are offline even though the app has cached drafts and help content.A blank white page with only 503 in the browser title.
Good UX A user on an older browser books an appointment through labeled date fields even though the calendar enhancement never loaded.A user whose address is missing from the lookup switches to manual entry with the postcode and application reference retained, completes the same application, and can return to lookup without losing typed fields.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 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 A user must enable JavaScript to continue even though the server could accept the same date fields.A user tries the same failed lookup five times because the manual route is hidden until after repeated failure.The app keeps a spinner on Save during airplane mode and never explains that no network request can start.Users repeatedly refresh because the page gives no recovery window or status update path.
Best fit A richer UI control, script, API, media layer, device capability, or third-party widget improves the task but is not essential to the outcome.A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish.Connection loss or server reachability changes the user's current task.A whole service, transaction entry point, or route is closed or not ready to handle requests.
Avoid when The missing capability is legally, security, or domain required and no simpler route can complete the task.The only honest next step is retrying the same operation after a transient failure.A single request failed while the rest of the app is reachable and an error state is clearer.Only one local section or action failed and users can recover inside the current page.
Required state Enhanced available state with the richer control active.Primary path available state.Online normal state with no offline warning.Planned maintenance page with start or return time.
Accessibility burden Start from semantic controls and labels that remain available before and after enhancement.Make the fallback option visible near the blocked control or step, not only in help text or after mouse hover.Announce significant connectivity changes with status messaging when they affect the current task.Use a unique page title and H1 that state the service is unavailable, not just a code.
Common misuse Treating JavaScript as mandatory for form submission when server-validated fields could submit the task.Hiding manual entry or support until users repeatedly fail.Showing only a browser-style offline page when useful cached or local content exists.Using a full-page spinner for a closed service.

Graceful degradation

UI or UX
UI + UX - Reduced-capability same-surface experience that preserves the core task
UI guidance
Show the baseline controls on the same surface as the failed enhancement: date fields behind a date picker, a location list behind a map, a file input behind drag-and-drop, readable content behind animation, and plain links behind scripted navigation.
UX guidance
Use graceful degradation when a richer layer is unavailable but the user can still complete the core task with a simpler interaction on the current page.
Good UI
An appointment date picker says Calendar unavailable, keeps Day, Month, and Year fields with a format hint, and lets users continue after valid entry.
Bad UI
A failed calendar script leaves an empty rectangle and a disabled Continue button.
Good UX
A user on an older browser books an appointment through labeled date fields even though the calendar enhancement never loaded.
Bad UX
A user must enable JavaScript to continue even though the server could accept the same date fields.
Best fit
A richer UI control, script, API, media layer, device capability, or third-party widget improves the task but is not essential to the outcome.
Avoid when
The missing capability is legally, security, or domain required and no simpler route can complete the task.
Required state
Enhanced available state with the richer control active.
Accessibility burden
Start from semantic controls and labels that remain available before and after enhancement.
Common misuse
Treating JavaScript as mandatory for form submission when server-validated fields could submit the task.

Fallback path

UI or UX
UI + UX - User-directed alternate route when the primary path cannot complete
UI guidance
Place the alternate route beside the blocked primary path with a label that names what changes, such as Enter address manually, Use cached report, Call support with reference, or Continue with paper evidence.
UX guidance
Use a fallback path when the primary route is unavailable, unsuitable, unsupported, or repeatedly failing, and users still need a credible way to complete the task.
Good UI
An address lookup says We could not find this address, keeps postcode SW1A 1AA visible, and offers Enter address manually, Try another postcode, and Get help with reference APP-2048.
Bad UI
A lookup returns No matches and only shows Search again, even though manual address entry is supported.
Good UX
A user whose address is missing from the lookup switches to manual entry with the postcode and application reference retained, completes the same application, and can return to lookup without losing typed fields.
Bad UX
A user tries the same failed lookup five times because the manual route is hidden until after repeated failure.
Best fit
A primary lookup, verification, upload, payment, search, device feature, online-only step, or channel can fail while the user still needs to finish.
Avoid when
The only honest next step is retrying the same operation after a transient failure.
Required state
Primary path available state.
Accessibility burden
Make the fallback option visible near the blocked control or step, not only in help text or after mouse hover.
Common misuse
Hiding manual entry or support until users repeatedly fail.

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.

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.
Decision rules
  • Use graceful degradation when the current page can still complete its core task after an enhancement layer fails, such as replacing a calendar widget with date fields, a map with a location list, or drag-and-drop with a file input.
  • Use fallback path when users must switch to another method, route, support channel, manual review path, or assisted service to complete the outcome.
  • Use offline state when the main constraint is connectivity and the experience needs cached content, local saves, sync queues, stale timestamps, reconnect behavior, or read-only mode.
  • Use service unavailable page when a whole service, transaction route, or entry point is closed, overloaded, under maintenance, or permanently replaced.
  • Graceful degradation must name the unavailable capability, keep user-entered data visible, retain the core action when possible, and avoid implying the enhanced version is required.
  • Progressive enhancement is the build strategy that starts from a baseline; graceful degradation is the user-visible reduced-capability state when a richer layer is missing or breaks.
  • Do not call a separate support route graceful degradation; once users leave the same surface for manual review, phone support, paper, or another channel, the work is a fallback path.
  • Do not call browser-default network failure graceful degradation; when the user loses connection, the owning pattern is offline state or a controlled offline fallback page.
  • Do not show a service unavailable page for one broken widget if the rest of the transaction can continue with a simpler control.
  • If the core task genuinely cannot be completed without the missing capability, graceful degradation must say which requirement blocks completion and give the safest saved-work or support handoff.
Inspect live examples
Failure modes
  • A calendar script fails and leaves a blank panel with no date fields.
  • A map widget fails and the location choice disappears even though a list is available.
  • Drag-and-drop is required for upload, so keyboard, touch, and older-browser users cannot choose files.
  • A Continue button stays disabled because an enhancement did not set a client-side flag, despite valid baseline form values.
  • The page tells users to enable JavaScript without preserving fields, explaining the blocked capability, or offering a core route.
  • A third-party widget outage is treated as a whole-service outage even though the transaction could continue without the widget.