Using LogRocket to capture and replay network requests for troubleshooting

If you've ever wrestled with weird frontend bugs, you know that "it works on my machine" is little comfort. Tracking down what actually happened—what requests went out, what came back, and why things broke—can eat hours, especially when you can't reproduce the issue. That's where LogRocket steps in: it records what users actually did, and, crucially, what network requests your app fired off at the time.

This guide is for engineers, QA folks, and anyone tired of sifting through vague bug reports. We'll walk through how to capture and replay network requests in LogRocket, what this feature is good for, and where it occasionally falls short. No sales pitch—just practical advice to help you debug faster.

Why Capture and Replay Network Requests?

You can have all the logs in the world, but if you can't see exactly what the browser sent, received, and in what order, you'll be guessing. Capturing network requests alongside user sessions means:

  • You see the real payloads. Not sanitized logs, not what you think the code did.
  • You get context. Which click triggered which API call? What was the user doing?
  • You cut down on back-and-forth. No more endless “can you send me a HAR file?” emails.

Replay is the cherry on top: you can try re-sending requests to see if the backend still responds, or to test a fix. It’s not magic, but it’s close.

Step 1: Getting LogRocket Set Up

If you’re already running LogRocket, skip ahead. Otherwise, here’s the quick-and-dirty:

  1. Sign up for an account on LogRocket’s site. There’s a free tier, but expect limits.

  2. Install the SDK. For a React app, it’s as easy as: bash npm install --save logrocket

  3. Initialize in your app’s entry point: js import LogRocket from 'logrocket'; LogRocket.init('your-app-id');

Swap in your actual project ID from LogRocket.

  1. Deploy. Push your changes and make sure your environment variables are set if you’re using them.

A quick word of caution: LogRocket records a ton by default. If you have sensitive data in your requests, read up on their sanitization options first. You don’t want to accidentally capture passwords, tokens, or PII.

Step 2: Capturing Network Requests

Once LogRocket is running, it’ll start collecting all XHR and fetch requests out of the box. Here’s what you actually get:

  • Request details: URL, method, headers, body.
  • Response details: Status code, headers, body.
  • Timeline: Exactly when each request happened in relation to user actions.

To see this in action:

  1. Open a LogRocket session replay. Click into a user session where the bug happened.
  2. Navigate to the 'Network' tab. It’s usually right next to the Console and Redux tabs.
  3. Browse requests. You’ll see a waterfall (like Chrome DevTools) of all requests.

Pro tip: If you’re only interested in certain endpoints (say, /api/orders), use the search or filter tools. Otherwise, you’ll drown in noise.

What’s Actually Useful?

  • Failed requests: Spot 4xx/5xx errors fast.
  • Payloads: See what the frontend really sent (not just what your code was supposed to send).
  • User-driven context: Match “user clicked submit” with “POST /api/checkout”.

What to Ignore

  • Tracking pixels, analytics junk, and other noise. Most apps are chatty. Don’t waste time debugging requests you don’t control.
  • Static asset requests (unless you’re debugging CDN/cache issues).

Step 3: Replaying a Network Request

This is where it gets interesting. Want to see if a failed request still fails? Or if your backend fix works? Replaying lets you send the exact same request again—right from the LogRocket UI.

How to do it:

  1. Find the request. In the Network tab, click on the request you want.
  2. Check the details. You’ll see the request body, headers, and response.

  3. Hit ‘Replay’. LogRocket will send the request to your backend, using the same method, URL, headers, and body.

  4. You’ll get a fresh response in the UI, so you can compare what changed (if anything).

  5. Modify before replaying: Some versions let you edit the payload before sending. Handy for quick experimentation.

What Works Well

  • Testing backend fixes: Deploy a fix, replay the old request, and confirm it works.
  • Investigating flaky endpoints: See if issues are transient or tied to user data.
  • Verifying data transformations: Did your frontend mangle the payload, or did the backend choke on good input?

What Doesn’t Work So Well

  • Requests with expired tokens: If the request depended on a short-lived auth token, replaying may fail.
  • Non-idempotent endpoints: Be careful replaying things like “delete” or “charge card” requests. You could trigger real side effects.
  • Frontend state: Replaying doesn’t recreate the whole app state—just sends the request again.

Bottom line: Replay is best for safe, idempotent requests (GET, some POSTs). Use it for debugging, not for “fixing” things in production.

Step 4: Using Captured Data for Real Debugging

Having the raw requests is nice, but here’s how to actually get value:

  • Compare good vs. bad sessions: Why did the request fail for one user and not another? Look for differences in payload, headers, or timing.
  • Spot race conditions: Requests made in the wrong order? See the timeline laid out next to user actions.
  • Bulk triage: Filter requests by status code to spot patterns (e.g., every PUT to /api/settings is failing).
  • Share a session: Instead of “works for me,” share a direct link so your teammates can see exactly what happened.

Pro tip: Pair network capture with console logs and Redux state (if you use it). Sometimes a bug only makes sense when you see all three together.

Security, Privacy, and Pitfalls

Capturing network traffic is powerful, but let’s be real: it can also go wrong if you’re not careful.

  • Sensitive data: Double-check that you’re not capturing auth tokens, passwords, or PII in request/response bodies. LogRocket has tools to redact or ignore fields—use them.
  • Compliance: If you’re in a regulated industry (finance, healthcare), talk to your legal team before logging real user data.
  • Performance: The SDK has a small overhead, but if you’re capturing huge payloads or running on slow devices, you might notice a slight lag.

Don’t skip sanitization. One slip and you could end up with sensitive data in the wrong place. It’s not worth the risk.

When LogRocket Network Capture Isn’t Enough

It’s good, but not perfect:

  • WebSockets and GraphQL: Coverage is improving, but it’s not as seamless as REST/XHR.
  • Obfuscated/minified requests: If your backend expects binary blobs or the payload is encrypted, you won’t get much insight.
  • Backend-only issues: If the problem is deep in server logic, seeing the request may not help much.

If you hit these walls, supplement with backend logs, API Gateway tracing, or old-fashioned curl requests.

Wrapping Up: Keep It Simple

Tools like LogRocket can seriously cut down on guesswork, but don’t let them lull you into overcomplicating things. Start with the basics: capture the bug, see what the network did, replay if it’s safe, and iterate from there. Don’t forget to sanitize, and remember—no tool is a silver bullet.

Debugging is still detective work, but at least now you’ve got the right magnifying glass.