HTTP error pages¶

Usage¶

HTTP error pages are full-page messages for request failures such as missing pages, missing permissions, or server errors.

They are built with the info page component as the base layout.

When to use¶

• When navigation to a page fails because the requested resource is unavailable or blocked.
• When an application route represents a standalone error state, such as 401, 403, 404, or 500.

Best practices¶

• Do not use them for transient background failures that can be communicated with inline notifications or toast notifications.
• Codes can be remapped deliberately (on server side) when necessary, for example showing a 404 page for a 403 error to avoid revealing that a restricted resource exists.

Design¶

Anatomy¶

1. Illustration
2. Heading: State the problem in a short, human-readable way with the error code.
3. Description (optional): Briefly explain what happened or what could have caused it.
4. Actions (optional): Offer a relevant escape path or recovery action.

Visual guidance¶

There are five predefined illustrations mapped to different error codes.

• Dedicated UX writing copy already exists for common error types.
• For less common errors that do not have dedicated UX writing copy, use the error code together with the official HTTP status title from the IANA HTTP status code registry.

Code¶