Page not found page vs Service unavailable page vs Error state vs Empty state

Choose page not found page when the user follows a broken link, mistypes or pastes an incomplete address, opens a removed page, or returns to an expired deep link and the product cannot resolve a valid destination.

Page not found page live example Service unavailable page live example Error state live example Empty state live example

Decision dimensions

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	Render a full page with site or service identity, a page title and H1 that state the page was not found, concise likely causes, and recovery routes such as search, start page, account dashboard, contact, or report-broken-link.	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.	Render a resolved no-data region with a specific heading, cause text, one primary action when available, optional secondary path, and restrained illustration or icon support.
UX guidance	Use a page not found page when the service is reachable but the requested URL, public page, resource, or deep link cannot be resolved.	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.	Help users recover when expected loading, saving, validation, sync, permission, or computation fails without losing their work.	Help users distinguish legitimate absence from loading, no-results, error, permission, and setup conditions before offering a next step.
Good UI	A benefits service 404 page says Page not found, shows the requested path only if safe, offers Search benefits, Start a new application, Report this link, and Contact support.	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.	Reports could not load appears in the report section with the saved filter, Retry, Use cached data, and Contact support actions.	No projects yet heading, short explanation, Create project primary button, Import CSV secondary button, and visible workspace context.
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.	A blank white table body with no text, object name, or action.
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	Users are sent to the homepage with no explanation and assume their task was lost.	Users repeatedly refresh because the page gives no recovery window or status update path.	Clearing work after save failure.	The same empty message appears for loading, search no-results, permission denial, and service failure.
Best fit	A route, URL, public page, file, object link, or deep link cannot be found.	A whole service, transaction entry point, or route is closed or not ready to handle requests.	A system or task failure blocks expected content or action.	The product area can legitimately contain no user data.
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	Use a unique page title and H1 that state the page was not found.	Use a unique page title and H1 that state the service is unavailable, not just a code.	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	Returning a successful status with page-not-found copy.	Using a full-page spinner for a closed service.	Using a transient toast for critical errors.	Showing a blank page with no explanation.

Page not found page

UI or UX: UI + UX - Missing-route recovery page
UI guidance: Render a full page with site or service identity, a page title and H1 that state the page was not found, concise likely causes, and recovery routes such as search, start page, account dashboard, contact, or report-broken-link.
UX guidance: Use a page not found page when the service is reachable but the requested URL, public page, resource, or deep link cannot be resolved.
Good UI: A benefits service 404 page says Page not found, shows the requested path only if safe, offers Search benefits, Start a new application, Report this link, and Contact support.
Bad UI: A bare 404 code with a single Home button.
Good UX: A user who mistyped a web address sees clear check-the-address advice and can search the service immediately.
Bad UX: Users are sent to the homepage with no explanation and assume their task was lost.
Best fit: A route, URL, public page, file, object link, or deep link cannot be found.
Avoid when: The service route exists but is temporarily closed, overloaded, or under maintenance.
Required state: Unknown route from typed or pasted URL.
Accessibility burden: Use a unique page title and H1 that state the page was not found.
Common misuse: Returning a successful status with page-not-found copy.

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.

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.

Empty state

UI or UX: UI + UX - Resolved no-data content surface
UI guidance: Render a resolved no-data region with a specific heading, cause text, one primary action when available, optional secondary path, and restrained illustration or icon support.
UX guidance: Help users distinguish legitimate absence from loading, no-results, error, permission, and setup conditions before offering a next step.
Good UI: No projects yet heading, short explanation, Create project primary button, Import CSV secondary button, and visible workspace context.
Bad UI: A blank white table body with no text, object name, or action.
Good UX: Users can create the first project, import existing work, or request access depending on the actual cause.
Bad UX: The same empty message appears for loading, search no-results, permission denial, and service failure.
Best fit: The product area can legitimately contain no user data.
Avoid when: The absence was caused by filters or search.
Required state: First-use empty state before any objects exist.
Accessibility burden: Keep the message in normal reading order near the empty region it explains.
Common misuse: Showing a blank page with no explanation.

Decision rules

Choose page not found page when the user follows a broken link, mistypes or pastes an incomplete address, opens a removed page, or returns to an expired deep link and the product cannot resolve a valid destination.
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 error state when a valid page or component fails to load, save, sync, authorize, or compute and recovery can happen within the surrounding shell.
Choose empty state when a valid page loads successfully and the resolved collection, dashboard, inbox, or workspace legitimately has no content.
A page not found page should keep service identity, state that the page cannot be found, explain likely causes without blame, and offer search, start page, dashboard, contact, report-broken-link, or current-task routes.
Do not auto-redirect from a page not found page without explanation; users need to know that their URL or link did not resolve and how to recover.
For protected or sensitive objects, use privacy-preserving not-found copy only when the product intentionally does not disclose existence; do not reveal private titles, owners, or record IDs unless access policy allows it.
Set the HTTP response and analytics so the missing URL is measurable as a 404, not a successful page with not-found copy or a service outage.

Inspect live examples

Page not found page Service unavailable page Error state Empty state

Failure modes

A missing route shows a bare code and leaves users without search, start, dashboard, contact, or report-broken-link routes.
A planned maintenance window is labeled page not found, so users think a valid service was removed or their bookmark is wrong.
A failed data load inside an existing route opens a 404 page, losing the user's filters, draft, and retry context.
A valid empty dashboard is treated as page not found, hiding the creation or setup action that should help the user start.
A protected record page reveals the record name and owner in the not-found copy, confirming sensitive resource existence.
A 404 page returns a successful status or redirects to the homepage, preventing teams from finding broken links and users from understanding what happened.