Choose a failure path
Compare HTTP response errors and runtime exceptions.
Open a case to inspect its status, loader behavior, and route boundary. Each example intentionally triggers a failure.
4xx · Client errors
Authentication, permissions, and missing resources.
- 404Open case
Not Found
Use this when a path or resource should report that it does not exist.
- 401Open case
Unauthorized
A request was understood, but the user is not authenticated.
- 403Open case
Forbidden
The request is known, but the current actor is not allowed to proceed.
Scenario details
- 404 · Not Found
- Throws a 404
Responseso the route boundary can render a missing-resource state. - 401 · Unauthorized
- Simulates a protected route where credentials are required before the request can continue.
- 403 · Forbidden
- Shows the difference between being unauthenticated and being blocked after authentication.
5xx · Server errors
Internal failures, upstream problems, and temporary downtime.
- 500Open case
Internal Server Error
A generic server-side failure became an HTTP error response.
- 502Open case
Bad Gateway
The app responded, but one dependency upstream failed first.
- 503Open case
Service Unavailable
The service is alive enough to answer, but not ready to fulfill the request.
Scenario details
- 500 · Internal Server Error
- Models an internal server failure where the route cannot produce a normal response.
- 502 · Bad Gateway
- Represents an upstream dependency that answered incorrectly or with unusable data.
- 503 · Service Unavailable
- Useful for downtime and maintenance states where the route should advertise temporary unavailability.
Runtime exceptions
A thrown JavaScript error instead of an HTTP response.
Scenario details
- ERR · Runtime Error
- Throws a normal JavaScript error instead of a
Response, which lets you compare the two failure shapes. The server-side log keeps the currentapp.session_idso you can match it to the browser issue.
How the error routes work
Prerendered index
/errorsis safe to prerender because it never throws. It works as a navigational map into the error cases rather than an error screen itself.Request-time loader
/errors/:codethrows from the loader to simulate real failures. That makes the page useful for seeing how SSR, status codes, and response headers behave when a route does not resolve normally.Route boundary
The route boundary catches the failure and turns it into the final visual surface. That means the page you see for
404,500, orruntimeis intentionally designed by the route, not by a browser fallback.