# Timeouts and slow pages

What a timeout actually means, and why raising the limit is usually the wrong response.

A timeout means a step waited for something that never arrived: an element that did not appear, a navigation that did not complete, a request that hung. The step gives up rather than waiting forever, and the run fails there.

![A failed run whose first failure is a step that waited for an element that never appeared.](https://testsnag.com/images/docs/troubleshooting/run-vs-test-failure-1-failed-run.r1.jpg)

Marked on the screenshot:
- One step failed. A timeout usually means it waited for something that never arrived.
- Open the failed group to read the error and see how long it waited.
- Compare the duration against previous runs before raising the timeout.
- Everything after the failure was skipped, not attempted.

## Read it as a signal first

Before adjusting anything, consider that the test may be right. A page that takes twelve seconds to show its main content is a page your customers are also waiting twelve seconds for. Timeouts on a journey that used to be fast are often the earliest warning you will get of a performance regression, and raising the limit throws that warning away.

## When it is the test

- The step waits for an element that never renders because an earlier step silently did not work.
- The journey genuinely includes a slow operation, such as a report that takes half a minute to generate.
- A third-party script the page waits on is slow or unreachable from the runner.
- The environment under test is a staging box that sleeps when idle and needs a moment to wake.

## What to change

Where the wait is legitimate, extend the timeout on that specific step rather than slowing the whole test down. Where an earlier step is the real culprit, fix it there and the timeout disappears. Where the target environment is simply slow, consider pointing the test at something more production-like, since a test against an unreliable environment mostly measures the environment.

> **Note:** The network log captured with each run shows which requests were still in flight when the step gave up, which usually names the culprit directly.