Error handling
Error routesResponses and runtime failures
A static index for the failure paths the app can intentionally trigger.
Use this page to jump into thrown response errors, runtime exceptions, and the route boundaries that present them. The hub itself is prerendered; each case underneath is a live server-rendered incident surface.
Choose a failure path.
Every route below demonstrates a different way the app can fail and how the route-level boundary reshapes that failure into something inspectable.
Not Found
Use this when a path or resource should report that it does not exist.
Throws a 404 `Response` so the route boundary can render a missing-resource state.
Open caseUnauthorized
A request was understood, but the user is not authenticated.
Simulates a protected route where credentials are required before the request can continue.
Open caseForbidden
The request is known, but the current actor is not allowed to proceed.
Shows the difference between being unauthenticated and being blocked after authentication.
Open caseInternal Server Error
A generic server-side failure became an HTTP error response.
Models an internal server failure where the route cannot produce a normal response.
Open caseBad Gateway
The app responded, but one dependency upstream failed first.
Represents an upstream dependency that answered incorrectly or with unusable data.
Open caseService Unavailable
The service is alive enough to answer, but not ready to fulfill the request.
Useful for downtime and maintenance states where the route should advertise temporary unavailability.
Open caseRuntime Error
A runtime exception escaped the route logic and was caught by the route boundary.
Throws a normal JavaScript error instead of a `Response`, which lets you compare the two failure shapes. The server-side log keeps the current `app.session_id` so you can match it to the browser issue.
Open caseWhat to notice.
The interesting split is between the static entry page, the dynamic route loader, and the boundary that formats both response errors and thrown exceptions.
Static hub
/errors is safe to prerender because it never throws.
It works as a navigational map into the error cases rather than an error screen itself.
Dynamic incident routes
/errors/:code throws 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.
Boundary formatting
The route boundary catches the failure and turns it into the final visual surface.
That means the page you see for 404, 500, or runtime is intentionally designed by the route, not by a browser fallback.
Start with /errors/404 or /errors/runtime to compare a thrown response with a thrown JavaScript error.