Open network.har in a trusted HAR viewer or inspect its JSON in your editor. Search and filter it with the tool you already use.

Find the relevant entry

Start with the failing action in session.md. Convert its relative offset to an approximate absolute time using the session start, then search log.entries by startedDateTime, method, URL, subject identifier, or payload value.

Confirm the candidate with more than timing. Match the same record ID, operation name, request body, or returned object. Background requests and polling can occur near the same action.

Inspect the request and response

For the selected entry, compare:

• request.method, request.url, query parameters, headers, cookies, and postData;
• response.status, headers, cookies, and content;
• HAR timing fields and the request’s absolute start time;
• redaction markers, missing text, truncation, and binary placeholders.

An HTTP 200 can still contain an application error or returned state that violates the expected behavior. For GraphQL, inspect the operation payload, returned errors, and partial data together.

HAR timing is browser-observed request timing, not the tester’s complete wait or a server profiler. Compare it with the visible result described in session.md, notes.md, and screenshots.

Understand what is absent

The standard bundle’s HAR represents captured HTTP traffic. It does not preserve the Recorder network Viewer’s filters, source links, WebSocket frame list, or every EventStream detail. A missing body or stream message is an evidence gap, not proof that the server sent nothing.

If stream content is decisive, ask the tester to preserve the observation in Description or notes.md, or collect it with an appropriate browser or protocol tool in a new authorized attempt.

Use Reproduce a request only after a read-only inspection and only when replay will answer a specific remaining question.