Blog · Learn · 2026-06-23

Capturing Network Requests for Bug Reports That Get Fixed

Klavity
TL;DRA bug report without network context leaves developers guessing. Capture the failing request's URL, method, status code, request payload, and response body — then attach them alongside your screenshot and console log. That combination alone eliminates the most common 'cannot reproduce' excuses.

A screenshot shows what broke. A console log shows the JavaScript error. But a network request capture shows why it broke — the server's actual response, the payload your app sent, the status code that caused the failure.

Without network context, a developer looking at a bug report has to guess: Did the API return a 401? A 500? Did the client send the wrong payload? Did the response body come back empty when it should have had data? Each guess means another round-trip of questions. With network context, they can skip straight to the fix.

What to open first

Open Chrome DevTools (F12 or Cmd+Opt+I), switch to the Network tab, and check Preserve log before you do anything else. This prevents requests from clearing when the page redirects — a critical step because many bugs involve a form submission followed by a redirect, and the failing POST disappears if you forget this checkbox.

Then reproduce the bug. Every request made during that session is now captured.

Which requests actually matter

Filter to Fetch/XHR to see only API calls and eliminate noise (fonts, images, analytics pings). Now look for:

  • Red rows — any 4xx or 5xx response. These are almost always the direct cause of a bug.
  • The last successful request before the error appeared — often reveals a race condition or a missing dependency.
  • Requests with unexpectedly empty response bodies — a 200 that returns {} when your app expected an array is a common silent failure.

What to copy for the bug report

For each relevant request, copy four things:

  1. URL and method — e.g. POST https://api.example.com/checkout/complete
  2. Status code — e.g. 422 Unprocessable Entity
  3. Request payload — the JSON body you sent (redact passwords and tokens)
  4. Response body — what the server returned (first 200 lines is enough for most cases)

Paste these as code blocks in the bug report. Plain text is far more useful than a screenshot of the DevTools panel — the developer can copy-paste a JSON payload and test against it immediately; they cannot do that with an image.

The HAR file: when one request isn't enough

If the bug involves a sequence of requests — an auth flow, a checkout, a multi-step wizard — export a HAR file instead. Right-click anywhere in the Network panel, select Save all as HAR with content. This gives the developer a complete session log with timing, headers, and bodies for every request.

Attach the HAR file to the ticket. Most modern bug trackers accept file attachments. HAR files open in browser DevTools and in dedicated viewers like har.tech — the developer can replay the exact session on their machine.

What not to include

Network captures can contain sensitive data. Before attaching anything, scan for:

  • Authorization headers — bearer tokens, API keys. Replace with [REDACTED].
  • Cookie headers — session identifiers. Replace with [REDACTED].
  • PII in request bodies — email addresses, names, payment details in test data are fine; real user data should be anonymized.

If your team uses a shared bug tracker that's accessible outside your organization, be especially careful. A leaked bearer token is a security incident, not just a bug report.

Tying it together

The best bug report format for network-related issues looks like this:

  1. Steps to reproduce — numbered, starting from a logged-out or fresh state
  2. Expected vs. actual — one sentence each
  3. Screenshot — the visible error state
  4. Console log — any errors logged at the moment of failure
  5. Network request — URL, method, status, payload, response body

That five-part structure gives the developer everything they need to reproduce, understand, and fix the bug without asking a single follow-up question. Network data is the part most reporters skip — which is exactly why including it makes your report stand out.

Key takeaways

  • Always capture failing requests (4xx/5xx) and the last API call before an error — these two usually pinpoint the bug.
  • Include URL, method, status code, request body, and the first 200 lines of the response body as plain text.
  • Redact Authorization headers, cookies, and PII before attaching network data to any ticket.
  • Use 'Preserve log' in DevTools to prevent requests from disappearing on redirect or page load.
  • A HAR file (exported from the Network panel) is the gold standard — it includes timing, headers, and bodies in one file.

FAQ

Which network requests should I include in a bug report?

Focus on requests that failed (4xx/5xx status), requests that returned unexpected data, and the last few requests made before the error appeared. Avoid attaching every request — a 200-response for a font file is noise. The DevTools Network tab lets you filter by XHR/Fetch to see only API calls.

Is it safe to include request payloads in a bug report?

Redact passwords, tokens, and PII before attaching. Most bug tracker tools accept plain text, so copy the payload as JSON and manually blank sensitive fields. Never screenshot a request that contains an Authorization header or a session cookie — copy the payload body only.

What if the failing request only happens in production?

Use your browser's network panel in production (it works the same way). If you can reproduce the bug on demand, capture it live. If it's intermittent, set up a Fetch observer or a service worker that logs failing responses to localStorage — then retrieve those logs when the bug occurs.

How do I capture a network request that disappears on page refresh?

In Chrome DevTools Network tab, check 'Preserve log' before you trigger the action. This keeps all requests across page navigations. You can also use 'Save all as HAR with content' to export the full session for the developer.

Catch bugs the moment a human sees them

Klavity: right-click bug reports, AI personas that review your product, and self-healing tests.

Get started free