Field note
Capturing a HAR file that actually helps
A HAR file is a recording of every request a browser made, including headers, timings and bodies. For an integration that fails somewhere between two systems, it is usually the single most useful artefact in existence — it replaces every round of 'can you describe what happened' with the actual exchange.
Most HAR files that reach support are unusable. Not because capturing one is hard, but because of when it was started and what was done in between.
Capturing one that shows the failure
- Open DevTools and go to the Network tab before reproducing the problem. A recording started afterwards has missed the thing you need.
- Enable the option to preserve the log across navigations. Without it, any redirect — including the ones in an authentication flow — wipes exactly the requests that matter.
- Clear the existing entries, then reproduce the failure and nothing else. A capture containing one reproduction is worth more than one containing twenty minutes of general use.
- Note the wall-clock time you reproduced it. That lets anyone investigating correlate your capture against server-side logs.
- Export as HAR immediately, before navigating away.
Before you send it anywhere
A HAR contains everything the browser sent, which means session cookies, authorization headers, tokens and any personal data in request or response bodies. Anyone holding the file can generally act as you until those credentials expire.
Treat it as a credential, not a log file. Strip authorization headers and cookies before sending it outside your organisation, or use a sanitiser. If it must go to a third party, send it through something access-controlled rather than as an email attachment, and rotate anything sensitive afterwards.
This applies even to vendors you trust. The risk is not usually the vendor — it is the ticketing system the file ends up in and the number of people with access to it.
Reading it: what to look at first
The instinct is to search for red entries. That is often a dead end, because the request that visibly fails is frequently a consequence rather than a cause.
- Find the first request that behaved unexpectedly, not the first that errored. A 200 response carrying an empty or partial body is a more common root cause than a 500.
- Check the authentication exchange specifically. Token acquisition failing quietly leaves every subsequent call failing in ways that look unrelated.
- Compare timings across requests. A single call taking dramatically longer than its neighbours points at a bottleneck rather than a logic error, and those need different fixes.
- Look at what was actually sent, not only what came back. A malformed or incomplete request body explains a great many confusing responses.
- Watch for retries. Repeated identical requests usually mean something upstream timed out and re-sent — which is also how duplicate records get created.
Why this is worth the effort
The value is that it converts an argument into an observation. 'The integration is broken' invites disagreement. 'This request returned 200 with an empty payload at 14:32:06, and the call before it never completed' does not.
I ran HAR analysis daily for three years across LinkedIn Talent Solutions integrations, and the pattern was consistent: cases where someone had captured the failure properly resolved in a fraction of the time, regardless of whose fault the problem turned out to be.
If you are opening a support case with any integration vendor, this is the highest-leverage twenty minutes you can spend beforehand.
Have a capture and no idea what it is telling you?
Reading these is most of what I do. If you can reproduce a failure and capture it, that is usually enough to establish what is actually happening.
Get in touch →