Fallback path vs Retry vs Error state vs Service unavailable page

Use fallback path when users should switch to a different method such as manual entry, evidence upload, cached data, assisted support, paper route, or alternate channel.

Fallback path live example Retry live example Error state live example Service unavailable page live example

Decision dimensions

Dimension	Fallback path	Retry	Error state	Service unavailable page
UI or UX	UI + UX - User-directed alternate route when the primary path cannot complete	UI + UX - Scoped failed-operation retry control	UI + UX - Recoverable failure surface	UI + UX - Whole-service unavailable page
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.	Place Retry next to the failed operation, object, or request summary, and name the exact action being retried such as Retry export or Retry payment authorization.	Render a persistent error region near the affected content with a specific failure heading, plain-language cause, preserved context, and recovery actions.	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 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 retry when a specific operation likely failed for a transient reason and the same operation can be attempted again without losing user context or duplicating side effects.	Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.	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 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 report export card says Export CSV failed, keeps the saved filters visible, shows Attempt 1 of 3, and offers Retry export with request EXP-2048.	Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.	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 lookup returns No matches and only shows Search again, even though manual address entry is supported.	A generic Try again button appears after every error, including validation and permission failures users cannot fix by repeating the request.	Tiny transient toast for a blocking failure.	A blank white page with only 503 in the browser title.
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.	A user retries the same export after a network timeout, sees the attempt change to sending, and then returns to the recovered download state without re-entering filters.	User input and filter context are preserved after failure, and retry returns to recovered content or a clear still-failed state.	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 tries the same failed lookup five times because the manual route is hidden until after repeated failure.	The app retries aggressively every second during an outage and makes the service harder to recover.	Clearing work after save failure.	Users repeatedly refresh because the page gives no recovery window or status update path.
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.	A load, save, submit, upload, export, sync, payment, or background request failed for a transient or uncertain reason.	A system or task failure blocks expected content or action.	A whole service, transaction entry point, or route is closed or not ready to handle requests.
Avoid when	The only honest next step is retrying the same operation after a transient failure.	The error is caused by invalid user input and correction is required.	Nothing exists yet and the state is expected.	Only one local section or action failed and users can recover inside the current page.
Required state	Primary path available state.	Retryable failed state with affected operation, object, and preserved request context.	Normal expected state before failure.	Planned maintenance page with start or return time.
Accessibility burden	Make the fallback option visible near the blocked control or step, not only in help text or after mouse hover.	Use an action label that names the operation, not only an icon or generic phrase.	Use appropriate alert or status semantics for newly appearing critical errors.	Use a unique page title and H1 that state the service is unavailable, not just a code.
Common misuse	Hiding manual entry or support until users repeatedly fail.	Offering Retry for every error regardless of whether the user or system state can change.	Using a transient toast for critical errors.	Using a full-page spinner for a closed service.

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.

Retry

UI or UX: UI + UX - Scoped failed-operation retry control
UI guidance: Place Retry next to the failed operation, object, or request summary, and name the exact action being retried such as Retry export or Retry payment authorization.
UX guidance: Use retry when a specific operation likely failed for a transient reason and the same operation can be attempted again without losing user context or duplicating side effects.
Good UI: A report export card says Export CSV failed, keeps the saved filters visible, shows Attempt 1 of 3, and offers Retry export with request EXP-2048.
Bad UI: A generic Try again button appears after every error, including validation and permission failures users cannot fix by repeating the request.
Good UX: A user retries the same export after a network timeout, sees the attempt change to sending, and then returns to the recovered download state without re-entering filters.
Bad UX: The app retries aggressively every second during an outage and makes the service harder to recover.
Best fit: A load, save, submit, upload, export, sync, payment, or background request failed for a transient or uncertain reason.
Avoid when: The error is caused by invalid user input and correction is required.
Required state: Retryable failed state with affected operation, object, and preserved request context.
Accessibility burden: Use an action label that names the operation, not only an icon or generic phrase.
Common misuse: Offering Retry for every error regardless of whether the user or system state can change.

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.

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 fallback path when users should switch to a different method such as manual entry, evidence upload, cached data, assisted support, paper route, or alternate channel.
Use retry when the same operation should be attempted again with the same request context and duplicate-submit protection.
Use error state when a failure needs a persistent explanation, affected-context display, and recovery actions, one of which may be a fallback path.
Use service unavailable page when the whole service, transaction route, or entry point is closed, overloaded, under maintenance, or permanently replaced.
Fallback path must say what changes between primary and alternate routes: method, data carried over, timing, validation, support ownership, and whether completion remains in the product.
Do not label a retry button as fallback unless it changes the route or method; repeating the same failing lookup, payment, upload, or request is retry.
Do not offer fallback paths that clear saved work, hide references, create duplicate submissions, or route users to a channel that cannot finish the task.
When the primary issue is a no-result lookup, provide manual entry or assisted lookup before users are trapped in repeated searches.
When a service unavailable page includes an alternate channel, the fallback path still needs its own completion contract, support hours, saved-work state, and reference handoff.
If no fallback exists, say so directly and give the safest next step instead of inventing a dead-end download, homepage link, or support queue.

Inspect live examples

Fallback path Retry Error state Service unavailable page

Failure modes

A no-match lookup only offers Search again even though users can enter the record manually.
A fallback link restarts the journey and drops the application reference without warning.
A phone support route is shown with no reference, hours, required information, or tracking status.
A full service outage page links to a homepage and calls it an alternative path even though the task cannot be completed there.
An error state hides the fallback in a support article rather than making it part of the recovery surface.
A retry loop is presented as an alternate path, so users repeat the same broken operation instead of switching methods.