Both. Ory’s “flow error” data is designed to power a user-facing error page and also to help developers debug. - User-facing: When a browser flow hits a user-facing error (for example, an expired login flow), Kratos stores the error and redirects the browser to your Error UI with an id you can use to fetch structured error details at /self-service/errors. This is meant for you to render meaningful messages to the end user (e.g., request expired, invalid credentials), not just for debugging. There are even stub errors to help you build that page. [[User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors); [getFlowError](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json)] - Structured messages for UI: Flows and UI nodes carry request-, method-, and field-level messages with stable IDs, default text, and optional context so you can present clear, localized, and actionable feedback in your UI. [[Titles, labels, messages](https://www.ory.sh/docs/kratos/concepts/ui-user-interface#titles-labels--validation-messages); [Error handling](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#error-handling)] - Developer debugging: The same error payloads include details useful for diagnosing issues (e.g., reason/debug fields). If a system error occurs, you’re redirected to the Error UI, where you can fetch the error object for investigation. [[User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors)] So, the error flow information is intended to be shown (appropriately) to end users and is also helpful for developers during troubleshooting.

Short answer: “User-facing” errors that Kratos decides should be shown in your Error UI. Details: - Kratos redirects the browser to your configured Error UI (e.g., /error?id=...) when a user-facing error occurs during self-service flows (login, registration, settings, etc.). You then fetch the error via GET /self-service/errors using the id. The payload includes a structured error object with keys like code, message, reason, and debug. [[User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors); [getFlowError](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json)] - Examples provided in the docs include: - System/internal errors (e.g., “Internal Server Error”), available as a stub via id=stub:500 for building your UI. [[User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors); [getFlowError](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json)] - Flow/request state errors such as an expired flow, session already exists, CSRF violations, return_to not allowed, or browser_location_change_required. These are mentioned as possible error.ids when submitting flows and can surface as user-facing errors that lead to your Error UI depending on context. [[updateLoginFlow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json); [updateSettingsFlow](https://raw.githubusercontent.com/ory/kratos/master/spec/api.json)] - If you haven’t configured an Error UI, Kratos shows a fallback page instructing you to set selfservice.flows.error.ui_url, which implies you’d otherwise be routed there for user-facing errors. [[This should be the Error UI](https://www.ory.sh/docs/kratos/fallback/error)] What you’ll see on /error: - A JSON error container fetched via /self-service/errors?id=..., containing: code (HTTP-like status), message, and optionally reason and debug. You decide how to present these to the user (e.g., “Your login request expired. Please start again.”). [[User-facing errors](https://www.ory.sh/docs/kratos/self-service/flows/user-facing-errors)]