An unresponsive Save button does not prove an API failure. The request might never leave the page, be blocked, return an HTTP error or return 200 with data the application cannot process. Chrome DevTools Network helps separate these cases.
Inspect only sites you own or are authorized to test. Prefer test accounts and data; do not repeat real payments or production mutations merely to capture traffic.
1. Capture one clear reproduction
Chrome's Network tutorial explains opening DevTools and selecting Network to observe requests. The browser menu offers access when keyboard shortcuts differ by platform.
- Record the time, page path and failing action.
- Open Network, confirm recording and clear the displayed old log.
- Reproduce once using test data.
- Filter Fetch/XHR for API calls; inspect other types if necessary.
- Select the relevant request and inspect Headers, Payload, Response and Timing.
No visible request does not mean the server received and lost it. Check filters, capture timing and JavaScript errors before blaming the backend.
2. Match observations to investigation layers
| Observation | Next checks |
|---|---|
| No relevant request | UI event, client validation, JavaScript errors or filters |
| HTTP error response | Status, response body and server logs |
| No complete HTTP response | Connection, cancellation, TLS or browser policy |
| 200 with a UI failure | Data format, business errors in the body or subsequent processing |
This is a hypothesis framework, not an automatic diagnosis. A browser-side CORS failure does not establish that the server never performed an action; avoid blind retries of side-effecting requests.
3. Control cache and navigation deliberately
The Network reference describes Preserve log across navigation and Disable cache for browser caching while DevTools is open. Enable them for a specific question and record their state.
Observe normal user conditions first, then make a separate cache-disabled observation if needed. Do not mix the results into one performance claim. Disable cache is not proof that CDN, server or service-worker caching has also been disabled.
4. Interpret timing conservatively
Timing separates request phases, but waiting for the first response byte is not a database-only stopwatch. To identify server work, correlate with logs or traces using a request identifier when available.
Record the endpoint, duration, outcome and recurrence. A long waterfall bar alone cannot establish a slow database. Also distinguish network transfer from later UI processing.
5. Treat HAR exports as sensitive
Chrome supports sanitized HAR exports excluding selected headers such as Cookie, Set-Cookie and Authorization. URLs, query strings, payloads and responses can still contain customer data or credentials placed elsewhere by an application.
Limit capture scope, inspect the result and redact under your organization's process. Do not upload HAR files to public issues or unfamiliar analysis sites. Copy as cURL can include credentials too; do not paste an unreviewed command into public conversations.
6. Build a useful bug report
- Time with timezone and browser version.
- Reproduction steps with anonymized inputs.
- Endpoint, method, observed status and request ID if available.
- Expected versus actual behavior.
- Cache, throttling and Preserve log settings.
- Reviewed screenshots or HAR shared through approved channels.
A useful report need not contain an entire browsing session. One focused reproduction with context and carefully handled evidence is often more actionable.
No comments yet. Be the first to share your thoughts.