You have only the trace zip from a Playwright run where an order-tracker test timed out in CI. Which Trace Viewer tabs do you read, and what does each settle?

## Start from the failing action, not the top The Actions list is ordered, timed, and marks the action that failed. Open it there. Reading a trace forwards from the first `goto()` wastes the one advantage the viewer gives you: it already knows which call ran out of time. Select that row and every other pane in the window rebinds to it. Then work outwards. Each tab settles a different question, and knowing which tab settles which is most of the skill. ## The tab map | Tab | What it holds | What it settles | |---|---|---| | **Actions** | Every recorded call, in order, with durations | Which step failed, and how long the ones before it took | | **Call** | The call's parameters, duration and result | Whether you targeted the thing you meant to target | | **Log** | The call's internal progress entries | What the call was waiting for while the clock ran down | | **Console** | Messages the page emitted | Whether the app threw and stopped rendering | | **Network** | Requests with headers, timings and bodies | Whether the data the UI needed ever arrived | | **Source** | The test file with the current line highlighted | Which line of your code issued this call | | **Attachments** | Files the run attached to the test | Extra evidence recorded alongside the trace | | **Metadata** | Browser, viewport and run details | Whether the environment differed from your machine | ## A reading order that converges fast For an order tracker whose test timed out waiting on a delivery-status element: 1. **Actions** — confirm which call failed and note how long the preceding calls took. A slow `goto()` followed by a fast failure tells a different story from one long wait at the end. 2. **Before snapshot** — was the element on the page at all? If the page is showing a skeleton loader, you are looking at a data problem, not a locator problem. 3. **Call** — read the arguments actually recorded. A selector built from a template string can differ from the one you believe you wrote. 4. **Log** — read what the call reported while it waited. This is where a call that found the element but never got it into a usable state separates from one that never found anything. 5. **Network** — find the request behind the missing content. A `/api/orders/8412/status` entry that returned 500, returned an empty payload, or is still pending at the end of the trace explains an empty UI immediately. 6. **Console** — check for an exception thrown by the page. A crashed render leaves the DOM frozen mid-update and every downstream locator fails for the same reason. 7. **Source** — jump to the test line to see the assertion in context before you decide the fix. ## What the trace can and cannot tell you The trace ends where the browser ends. It is complete about what the page did and utterly silent about what the server did internally: - It shows a request went out, its headers, its status and its body — not why the service produced that status. - It shows a long wait — not what the CI host was doing while it waited. - It shows the DOM as recorded — not state living only in component memory. ## Reading Metadata before blaming CI When a test passes locally and fails on a build machine, the Metadata pane is worth thirty seconds early rather than an hour late: browser and version, viewport size, and run details. A narrower viewport that pushes the delivery-status panel below the fold, or a different browser engine, is a mundane and very common explanation that costs nothing to rule out. ## Habits worth building - Read **Call before Log**: know what you asked for before you read what it did. - Treat a **timeout as a symptom**, then let Network and Console compete to explain it. - Check the **action immediately before** the failure. A fill that silently targeted the wrong field is invisible until you look one row up. - Keep the failing trace open next to a trace from a passing run of the same test; comparing two Actions lists side by side finds a diverged step faster than any amount of reasoning about one.