> ## Documentation Index
> Fetch the complete documentation index at: https://docs.testorim.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Browser failures

> When the page, not the step, is what went wrong.

## The page returned an error status

A `navigate` step reads the response status, so a page that 404s or 500s fails
there rather than three steps later on a confusing assertion.

| Status        | Attributed to | Reading                                                              |
| ------------- | ------------- | -------------------------------------------------------------------- |
| `5xx`         | **app**       | The site failed to serve that page. A real defect.                   |
| `404` / `410` | **test**      | That address does not exist. Check the URL the step names.           |
| `401` / `403` | **test**      | Access refused. Sites commonly answer `403` to an automated browser. |
| `429`         | **test**      | The site is rate-limiting this browser.                              |

For `403` and `429`, the site is often refusing the *automation*, not the
request. An environment header or a cookie that identifies the run as yours is
usually the fix.

## A dialog appeared

Native `alert`, `confirm` and `prompt` dialogs are accepted automatically so
they cannot freeze a run, and what appeared is recorded. The step that raised
it and the step after it can both assert on it.

## A download did not arrive

A step with a download expectation waits up to 10 seconds for the download
event. The file is captured either way; the expectation only decides whether
the step passes.

If nothing arrived, the click probably did not trigger a download, so check the
screenshot for a modal or a validation error in the way.

## The page moved while the step was starting

Resolution takes time and an app can redirect inside that window. Testorim does
not refuse the step: it settles, finds the target on the page the app is now
showing, acts, and records the move as a warning naming both addresses. A
target that is not on the new page fails naming both.

## Enter did nothing

Before pressing a submit key, Testorim checks the focused control can actually
act on it: a textarea, something with its own activation behaviour, a field
inside a form, or an element with a real key listener.

* If it can and the page ignored it, the field's own submit button is clicked
  instead and the keyboard gap is recorded as a warning. That gap is a real
  accessibility finding.
* If it provably cannot, the step fails as an app defect: this page is not
  operable by keyboard here.
* If a key was sent to nothing at all, the step fails rather than reporting a
  success that never happened.

## The run timed out

Raise the [time limit](/test-execution/browser-runs#limits) for flows that
legitimately take long. For an assertion waiting on a long operation, give the
step a generous timeout and describe the finished state loosely (*"wait until
the page shows it is complete"*) rather than guessing the exact completion
phrase.

## A spinner never went away

Settling honours loading markers for a bounded window, long enough for a real
spinner, short enough that a permanently-present loading wrapper cannot tax
every step. If a page is genuinely stuck loading, the step fails on its target
and the screenshot shows the spinner.

## "Internal error (browser evaluation failed)"

Testorim's own runner broke. It is never described as a fault of your site, it
never gets a retry, and it never satisfies a negative test. Please send us the
run id.


## Related topics

- [Support](/resources/support.md)
- [How it works](/introduction/how-it-works.md)
- [Run status](/test-execution/run-status.md)
- [Debugging a failed run](/test-execution/debugging.md)
- [Browser runs](/test-execution/browser-runs.md)