# When something goes wrong

> The pages the hosted sign-in UI shows when a flow cannot continue: throttles, locked accounts, lapsed sign-ins, refusals, unknown pages and server errors.

A refusal the user can fix stays on the form as a banner. These are the pages for the rest:
each says what happened and offers the way on. When the server recorded the failure under
a request ID, the page shows it as a **reference ID** with a copy button. An administrator
pastes it into the admin dashboard's **Troubleshooting** page
([Tracing a failed request](https://www.nauthera.io/docs/v1/troubleshooting#tracing-a-failed-request)), which
shows what the server recorded about that request.

## Too many requests

A throttle replaces the form, since submitting it again would only be refused. With the
server's `Retry-After` the page says how long to wait. **Try again** reloads the step.

<StoryScreenshot id="screens-error-pages-rate-limit--default" alt="Too many requests, with Try again" />
<StoryScreenshot id="screens-error-pages-rate-limit--with-reference" alt="Too many requests with a reference ID" />

## A locked or suspended account

With `auth.brute_force.reveal_lockout` off, the default, neither shows: a locked account
gets the throttle page above, and a suspended or blocked one is answered like a wrong
password. With it on, a lock from failed sign-ins lands on `/account-locked`, with **Try
again** and **Back to sign in** (or, with no application in the URL, the way back to the
app). The page does not say when the lock lifts. A suspended or blocked account, after the
right password, gets a banner on the sign-in form instead: *This account is unavailable.
Contact your administrator.*

<StoryScreenshot id="screens-account-locked--too-many-attempts" alt="Account temporarily locked, with Try again and Back to sign in" />

## A lapsed sign-in

Each step of a sign-in has to finish within a short time. A step whose sign-in has lapsed,
a second-factor step included, says so, with **Sign in again**, which resumes the
application's request. With no application in the URL it gives the way back to the app
instead.

<StoryScreenshot id="screens-error-pages-session-expired--default" alt="Your sign-in session expired, with Sign in again" />

## Access denied, not found, server error

<StoryScreenshot id="screens-error-pages-forbidden--with-reference" alt="Access denied, with a reference ID" />
<StoryScreenshot id="screens-error-pages-not-found--default" alt="Page not found, with Back to login" />
<StoryScreenshot id="screens-error-pages-server-error--default" alt="Server error, with Try again" />

## Return to your app

The sign-in screen answers `404` when its URL names no application, so a page reached
without one cannot offer it. Each such page says instead: *To continue, go back to the app
you came from and sign in there.* The server sends a flow that no longer names its
application, such as a social sign-in that came back after it lapsed, to `/return`, which
says the same.

<StoryScreenshot id="screens-error-pages-return-to-app--default" alt="Return to your app" />
<StoryScreenshot id="screens-error-pages-not-found--without-app" alt="Page not found, with the way back to the app" />
