DebuggingIntermediate4-6 min reference
Network Debugging
Half of "the page is broken" bugs are really a failed or malformed request. The Network tab tells you instantly whether the frontend, the backend, or the connection is at fault — which decides who gets the bug. This sheet is the reading guide; for the panel basics see Browser DevTools for QA, and to dissect a saved capture see HAR File Analysis (linked below).
Read a request in this order
- Status —
2xxok ·4xxclient/request ·5xxserver ·(failed)/(canceled)·0/CORS. - Timing — slow TTFB = backend; slow content = payload/network.
- Request — method, URL, headers (auth!), payload — did the frontend send the right thing?
- Response — body + headers — did the backend return the right thing?
- Initiator — what triggered it.
Triage signals
| You see | Likely cause |
|---|---|
4xx with a bad/missing payload | Frontend sent wrong request |
4xx with a correct request | Backend validation / auth |
5xx | Backend bug — grab the response + server log |
| Request never fires | Frontend logic / event not wired |
| CORS error | Server CORS config / wrong origin |
| Pending forever | Timeout, backend hang, or blocked |
| 200 but UI wrong | Response shape changed — check the body |
Handy moves
- Preserve log across navigations/redirects.
- Filter to Fetch/XHR to cut noise.
- Copy as cURL to replay/escalate a request.
- Throttle to reproduce slow-network bugs.
- Check Disable cache for cold-load behaviour.
Common mistakes
- Reporting "broken" without checking whether the request even fired.
- Blaming the backend on a
4xxthat's actually a malformed frontend request. - Missing the failed call because Preserve log was off.
- Ignoring response headers (auth, content-type, CORS, caching).
// Related resources