Chrome DevTools Network Tab: Debug Failed Requests

A red request row tells you that something failed, not why the user saw the wrong result. Browser request debugging works best when you connect the user action, the initiating code, the response, and the application's handling of it into one reproducible sequence.

Capture the right request window

Open the Network panel before performing the failing action. Enable preserved logs only when navigation would otherwise erase useful evidence, then clear unrelated traffic. Capture scope matters: a full afternoon of requests makes a simple failure harder to isolate and increases the chance of collecting sensitive data.

Use the Unix timestamp converter to compare a sanitized epoch value from the request or response with your observation time. Confirm whether the value is seconds or milliseconds before drawing conclusions. A wrong unit can make a current request look decades out of date.

Write down the route, action, and approximate time. Include whether the browser was offline, throttled, using an extension, or serving a service-worker-controlled page. Those conditions can change the result without requiring any server-side change.

Identify the request that owns the symptom

Filter by resource type and a distinctive path fragment, then trigger the action once. Do not assume the first failed row caused the visible issue. A harmless analytics request may fail while the important application request returns a successful status containing unexpected data.

The Chrome Network guide explains request recording and inspection. Check the initiator chain to connect a row to the code path or document that started it. If several identical requests occur, compare their start times and request bodies before selecting one for deeper inspection.

const response = await fetch("/api/preview", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({ documentId: "demo-42" })
});
console.log(response.status, response.headers.get("content-type"));

This snippet illustrates two useful observations, not a production error-handling pattern. In particular, a fetch promise can resolve for an HTTP error status. Inspect the status and application behavior separately rather than using the existence of a response as proof of success.

Look for cancellations as well. A cancelled request can be expected during navigation or a rapidly changing search input. It becomes a bug when the application handles that cancellation incorrectly or fails to start the replacement request.

Inspect headers, payload, and response separately

Begin with request identity: URL, method, query parameters, and body. Then check the response status and content type. A successful status with an HTML login page can explain a JSON parsing failure better than the frontend stack trace alone.

Use the JSON formatter for a redacted JSON response if the raw body is difficult to inspect. Preserve the relevant field types and missing-field behavior while replacing names, tokens, and customer content. A sanitized example should still reproduce the shape-related failure.

The MDN HTTP status reference helps interpret status categories, but do not infer business meaning solely from a code. An application may intentionally return an empty body for one operation and require a structured error body for another.

Compare request headers carefully without copying credentials into tickets. Cookies, authorization headers, signed URLs, and even query parameters can grant access. Evidence minimization means retaining only what another developer needs to understand the defect.

If the browser reports a cross-origin restriction, capture the relevant console message and the request sequence, including any preflight request. Do not “fix” the local investigation by disabling browser security and then claim the production problem is resolved. Browser enforcement is part of the behavior being diagnosed.

Interpret timing without jumping to conclusions

Use the Timing panel to distinguish queueing, connection setup, waiting, and download phases. A large total does not automatically indicate a slow application handler. Local throttling, connection reuse, service workers, and request priority can affect the observed result.

Read the Chrome Network reference for the exact labels in your browser version. Timing evidence is most useful when compared across repeated, similarly controlled runs. One unusually slow request is a lead, not a reliable performance conclusion.

Compare cached and uncached behavior intentionally. The DevTools disable-cache option usually applies while DevTools is open; it does not describe every user's normal browsing session. Note that setting in the bug report so another developer does not compare incompatible conditions.

When debugging stale data, inspect cache-related response headers and whether the response came from a service worker or browser cache. Keep this investigation focused on identifying the source of the observed bytes; broader caching policy changes require separate design and validation.

For time-correlated logs, record the timezone and preserve an unambiguous UTC timestamp. A request's application timestamp, browser start time, and server log time may use different clocks. Avoid claiming a precise causal ordering when those clocks are not synchronized.

Package a reproducible, sanitized report

A useful report includes a short action sequence, expected result, observed result, one representative request, and a minimal payload. Attach a HAR only when necessary and permitted. HAR exports may contain credentials and personal information, even when the visible screenshot looks harmless.

If you use Copy as cURL, inspect the command before sharing or running it. It may include cookies, bearer tokens, and a state-changing method. Replaying a purchase or deletion endpoint against production is not an acceptable debugging shortcut.

Keep any replay in an approved test environment using disposable data. State-changing calls need explicit care because a successful reproduction can create real effects. Prefer a narrow fixture when the defect can be demonstrated without replaying the original transaction.

Link the report to relevant Dev Tools workflow resources only as supporting context. The report itself should contain enough evidence for someone unfamiliar with your browser session to start investigating immediately.

After the fix, repeat the original action under the same conditions and verify the visible UI, not only the request row. A correct response can still be discarded by stale state or mishandled by the application. Close the loop between network evidence and user behavior.

Key takeaways

• Capture a narrow request window and identify the actual initiator.
• Inspect request identity, response content, and application handling independently.
• Compare timings under controlled conditions and label clock assumptions.
• Sanitize exports and replay only safe requests in approved environments.