Start with a request you can reproduce
The Network panel shows what the browser requested and what came back. Before changing application code, reproduce the problem once with developer tools open. In a current desktop version of Chrome or Firefox, open developer tools, select Network, and reload the page. Panel labels vary slightly between browsers, but the request list, headers, response, and timing views serve similar purposes.
For a small local example, use Node.js and a POSIX-compatible terminal. Run this command, then visit http://localhost:3000 in the same browser: node -e 'require("node:http").createServer((req,res)=>{if(req.url==="/"){res.writeHead(200,{"Content-Type":"text/html"});res.end("<h1>Network practice</h1>");return}res.writeHead(404,{"Content-Type":"application/json"});res.end(JSON.stringify({error:"Missing item"}))}).listen(3000)' . The server returns a page for / and a JSON 404 response for other paths.
With the page open, enter fetch("/missing").then(async r => console.log(r.status, r.ok, await r.json())) in the browser Console. The Network panel should show a request for /missing, while the Console reports 404, false, and the JSON error. This separates the visible page from the request you are investigating. Stop the server with Ctrl+C when finished.
Find the request before interpreting it
A busy page can generate requests for images, scripts, fonts, and data. Clear the Network list, perform only the action that causes the problem, then locate the new entry. Filtering to Fetch/XHR can help with requests made by JavaScript, but switch back to All if the entry is missing. Search by a distinctive path or filename rather than assuming the first red row is the cause.
Select the entry and check its request URL and method. A correct-looking path on the wrong host, an extra slash, or a GET where the server expects a POST can explain a surprising result. Check the query string and, for methods with a body, the submitted payload. Be careful with sensitive values: request headers and bodies may contain credentials or personal data, so avoid copying them into shared screenshots or bug reports.
If the request never appears, verify that the action actually ran. Check the Console for a JavaScript error, confirm that a click handler fired, and consider whether a cache, service worker, or conditional branch prevented a new network request. The absence of a row is a different clue from a row with an error status.
Distinguish HTTP errors from transport failures
An HTTP status is a response from a server. In the local example, 404 means the request reached the server and the server returned a response saying that path was not found. JavaScript fetch does not reject merely because the status is 404 or 500; inspect response.ok or response.status before treating the body as successful data. A successful HTTP status can still contain content your interface cannot use.
A request marked failed without an HTTP response needs a different investigation. Confirm that the host and port are correct and the server is running. Browser security rules, including cross-origin restrictions, can also prevent JavaScript from reading a response; the Console often provides a more specific message. Do not assume every failed-looking entry is a server outage.
Redirects deserve attention too. Inspect the request sequence or final URL if the response came from an unexpected location. A data request redirected to a sign-in page, for example, may leave the application trying to parse HTML as JSON. The status, final address, and response content together tell a more useful story than the status alone.
Compare the response with what the code expects
Open the Headers and Response views for the selected request. Check the response content type, then inspect the body itself. Does the endpoint return a JSON object, an array, an HTML document, or an empty response? If the code expects an object with an items property but receives an error object, a rendering failure may occur after the network exchange has completed normally.
The Preview view can make structured data easier to scan, but use the raw Response view when formatting might hide important details. For intermittent problems, compare a working request with a failing one: method, URL, query parameters, payload, status, response headers, and body. A small difference in an input can be more informative than a long stack trace.
Timing can help narrow a slow request, but it does not identify the root cause by itself. A long wait might reflect server processing, network conditions, or other delays. First establish which request is slow, then reproduce it under comparable conditions before drawing conclusions.
Turn an observation into a fix you can verify
Write down the smallest supported finding: for example, “GET /missing returns JSON with status 404, but the interface treats it as a successful result.” That is more actionable than “the API is broken.” Fix the relevant assumption, such as the URL, submitted data, response handling, or error message, and repeat the same action with the Network panel open.
After the change, check both sides of the outcome. The request should have the intended method and address, and the interface should handle the actual status and body appropriately. Keep an error path in the test: an interface that works only when every request succeeds remains difficult to diagnose the next time a response changes.
