Skip to content

Network requests and responses

Find a request and inspect its captured details.

Last reviewed Open Markdown

Use Network in the session viewer to inspect traffic around a check. Start with the action and observed result so you know which request matters.

  1. Open Investigate after stopping the recording.
  2. Select Network.
  3. Search for a URL, header, payload value, response text, or message.

Narrow the list with Response status, Method, or Source. More filters includes domain, exact status, duration, response size, and GraphQL filtering. Use Type to distinguish traffic such as WebSocket rows, Attention to narrow diagnostic findings, and Hide data: URLs or Hide extension URLs to reduce noise. From and To sliders isolate a time range. Use Reset filters if an expected request disappears from the list.

The Only caused by action filter uses inferred associations; it can exclude relevant traffic that has no recorded action link.

Select a request, then examine the relevant detail tabs:

  • Headers: Request and response headers and general information.
  • Payload: Request content and Query String Parameters.
  • Response: Captured response content.
  • Initiator: Available information about what initiated the request.
  • Timing: Available phases and waterfall evidence.
  • Cookies: Captured cookie details and available privacy controls. Values are initially masked; permitted review decisions can include originals in exports.
  • EventStream: Captured stream messages where available.

Search within the request details to find a field. Add a note to a request or a specific field when it explains the result.

An HTTP failure, a transport error, and an application-level error are different observations. GraphQL responses can contain errors with HTTP 200; inspect the response instead of relying only on status.

Missing, redacted, or truncated bodies are evidence gaps. They can result from capture rules, size limits, streaming behavior, or browser availability. A missing response does not establish that the server sent no data.

Example: a successful request with the wrong result

Section titled “Example: a successful request with the wrong result”

In the real sample, the In progress click occurs at +32.226 seconds. The following POST sends the card ID and status: "in_progress"; the next board response changes the status but retains the blocked value seen after entering Blocked. All six requests returned HTTP 200. Inspecting only failed requests would miss this finding.

For eligible uncaptured image responses in a local session, Load from cache attempts to read the browser’s cached image. It does not request it from the origin server. If that fails, Re-download image, when offered, makes a new request to the displayed URL and may use browser cookies or follow redirects. It can return a different image from the one seen during recording; the preview shows when it was retrieved.

Use Add as attachment only after checking the image. Record that it was retrieved later if timing matters. Masked URLs cannot be re-downloaded, and these controls are unavailable in stored-session review.

Use Copy and reproduce a request for cURL and HAR handoff. Review sensitive fields before copying or downloading. Streaming traffic explains evidence that does not carry into a standard HAR.