HAR Files: Your Secret Weapon for Debugging Production Issues
A user reports a bug. You can’t reproduce it. Your logs show nothing wrong. The bug only happens on their device, with their network, using their browser setup.
This is the most frustrating kind of bug to debug. And it’s incredibly common.
Most developers reach for more logging, more monitoring, more telemetry. But there’s a simpler solution that’s been hiding in plain sight: HAR files.
What is a HAR File?
A HAR file is an HTTP Archive. It’s just a JSON file that records everything your browser does on the network. Every request, every response, every header, every cookie, every timing.
The beautiful thing about HAR files is that they require zero setup. No instrumentation. No code changes. Just open DevTools, click “Save all as HAR”, and you have a complete recording of what actually happened.
Why HAR Files Matter
Here’s what makes HAR files special: they show you what actually happened, not what you think happened.
When you’re debugging locally, you control everything. Same browser, same network, same environment. But your users don’t live in your controlled environment. They have:
- Browser extensions that inject scripts
- Corporate proxies that modify requests
- Ad blockers that kill third-party calls
- Slow networks that timeout
- VPNs that route through different regions
A HAR file captures all of this. It’s a snapshot of reality from the user’s perspective.
What You Can Debug With HAR Files
The “Works on My Machine” Problem
You know this scenario. User says payment is broken. You test it—works fine. They insist it’s broken. You ask for screenshots, error messages, browser console logs. Nothing helpful.
Request a HAR file and suddenly you see it: a browser extension is injecting an extra parameter. Your backend validation rejects it. The payment fails. You’d never have caught this without seeing their actual network traffic.
API Failures
Server logs show a 500 error. But why? The HAR file has the full request body, all the headers, the exact error response. You can see if it’s a malformed request, a missing auth token, or a CORS issue.
Performance Problems
“Your site is slow” is not a useful bug report. A HAR file shows you the waterfall. That analytics script taking 8 seconds? That API call blocking render? That’s your bottleneck.
Third-Party Issues
Your code works. But the payment gateway is down. Or the CDN is routing through a slow region. Or the analytics provider is timing out. HAR files show all external dependencies and their response times.
Timing and Race Conditions
Sometimes the bug is about order, not content. API call B fires before API call A completes. Token refresh happens mid-request. HAR files show exact timing sequences.
How to Use HAR Files
Getting a HAR File
It’s embarrassingly simple:
- Open DevTools (F12)
- Go to Network tab
- Reproduce the issue
- Right-click → “Save all as HAR”
That’s it. No plugins, no configuration, no setup.
What to Look For
Open the HAR in Chrome DevTools. You’ll see a waterfall of requests. Here’s what matters:
- Red requests failed. Look at their status codes and response bodies.
- Long bars mean slow requests. Check if it’s server time or network time.
- Gray/blocked requests were cancelled or blocked by extensions.
- Look at the sequence. What fired first? What waited for what?
Most bugs reveal themselves immediately once you see the actual network traffic.
Real Examples
Case 1: The Mysterious Payment Failure
Payment works in staging. Fails for one user. HAR file shows a browser extension adding a tracking_id parameter. Backend validation didn’t expect it and rejected the request. Fix: whitelist unexpected parameters.
Case 2: Infinite Loading
Dashboard stuck loading forever. HAR reveals an analytics script taking 30 seconds to timeout. It was blocking everything else. Fix: load analytics asynchronously.
Case 3: Random Logouts
Users randomly getting logged out. HAR shows token refresh returning 401. Another API call fired before the refresh completed. Fix: queue requests during token refresh.
The Privacy Problem
HAR files contain everything. Cookies, auth tokens, API keys, user data. You can’t just ask users to send HAR files to a public bug tracker.
You need to sanitize them. Remove sensitive headers, redact request bodies, strip tokens. There are tools for this (har-sanitizer on npm), but the real solution is to make sanitization automatic.
Build it into your support workflow. When a user uploads a HAR file, sanitize it before anyone sees it. Better yet, build a tool that only extracts what you need—status codes, timing, request URLs—and discards everything else.
# Sanitize HAR files before sharing
npm install -g har-sanitizer
har-sanitizer input.har --output safe.har
Making It Part of Your Workflow
The best debugging tools are the ones you actually use. HAR files are only useful if you remember to ask for them.
Make it standard procedure. When a user reports a bug that you can’t reproduce, the first response should be: “Can you send me a HAR file?” Not “can you send screenshots” or “what’s the error message”—those are rarely helpful. The HAR file usually is.
Better yet, automate it. Capture HAR files automatically when errors occur. Use Puppeteer or Playwright to generate them in your test suite. Build HAR upload into your bug report form.
// Capture HAR on critical errors
window.addEventListener('error', async (event) => {
if (isCriticalError(event)) {
const har = await captureHARFile();
await sendToErrorTracking({ har, error: event });
}
});
The developers who debug fastest are the ones who get to the root cause fastest. HAR files get you there.
Advanced Uses
Once you’re comfortable with HAR files, you can do more interesting things.
Automated Analysis: Parse HAR files in CI to catch performance regressions. Fail the build if bundle size or request count exceeds thresholds.
Comparative Debugging: Generate HAR files for both working and broken states. Diff them to see what changed.
Error Tracking Integration: Capture HAR files automatically when JavaScript errors occur. Send them to your error tracking service alongside stack traces.
The point isn’t to use all these techniques. The point is that HAR files are just JSON. You can parse them, analyze them, diff them, aggregate them—whatever helps you debug faster.
Why This Isn’t More Common
If HAR files are so useful, why doesn’t everyone use them?
Mostly because people don’t know about them. They’re hidden in DevTools. They sound technical. Most developers have never heard of them.
The other reason is that they’re not magic. They only capture network traffic. If your bug is in JavaScript logic or rendering, HAR files won’t help. But a surprising number of production bugs are network-related. API failures, timing issues, third-party problems, performance bottlenecks—all visible in HAR files.
Start asking for HAR files. You’ll be surprised how often they solve problems that seemed impossible to debug.