Capture the request before guessing
When a page displays an error, the browser’s Network panel can show what it tried to request and what happened. You only need a desktop browser with built-in developer tools, such as a recent version of Chrome, Firefox, Edge, or Safari. Labels vary slightly by browser, but the main ideas are the same. You do not need to install a package or write code to follow this workflow.
Open developer tools, select Network, and reload the page or repeat the action that fails. For a form submission, open the panel before pressing Submit. If the problem happens during navigation, enable the option commonly called Preserve log so earlier requests remain visible. Use the Fetch/XHR filter for requests made by page scripts, or select All if you are looking for a document, image, script, or stylesheet.
First confirm that a matching request appears. If none does, check whether the action ran at all: a button handler might not have fired, validation might have stopped a form, or a script might have failed earlier. The Console panel can help with those clues. If a request does appear, select it and note its URL, method, status, and start time. These details give you a specific event to investigate instead of a general page error.
Check where the request went
Inspect the request URL carefully. Verify the hostname, path, query string, and protocol against what the application intended to use. A relative URL is resolved against the page’s location, so a request that looks like it targets an API may actually be going to the web server at an unexpected path. Also check the method: a server expecting POST may respond differently to GET.
Look at the request headers and, when applicable, the request body. Check that the expected data was sent and that its format matches the Content-Type header. For example, a server expecting JSON might not understand form-encoded data. Do not assume every visible field is correct merely because the request was sent. If authentication is involved, check whether the browser included the expected cookie or authorization header, but avoid copying credentials into bug reports or screenshots.
Redirects can also hide the original problem. If a request ends at a login page instead of an API response, inspect the redirect chain and the final URL. An API call that receives an HTML login page may later produce a confusing JSON parsing error. The parsing error is a symptom; the unexpected destination is the more useful clue.
Read the status and response together
A status code helps narrow the search, but it rarely tells the whole story. A 404 suggests the server did not find that route or resource. A 401 or 403 points toward an authentication or permission check. A 500-range response suggests the server encountered a problem while handling the request. These are starting points, not complete diagnoses; the response body may explain which condition occurred.
Open the Response or Preview tab and compare the returned content with what the page expects. Is it JSON, HTML, an empty response, or an error message? Inspect response headers when the format is unclear. A successful HTTP status does not guarantee that the application received useful data: a response can be valid at the HTTP level yet contain an application-level error or an unexpected shape. Likewise, an empty response may be intentional for a particular endpoint.
If the panel shows no HTTP status, the browser may not have received a usable response. Check the displayed failure reason and the Console. Possible causes include a disconnected server, a name-resolution problem, a certificate issue, a browser extension, or a browser security restriction. Avoid treating every failed entry as a server error; first establish whether the request reached the server and whether a response came back.
Separate cross-origin and timing problems
If the page and API have different origins, inspect Console messages alongside the Network entry. A cross-origin request may be sent but its response blocked from page scripts, or a preliminary OPTIONS request may fail before the intended request is made. In the latter case, check the OPTIONS entry and its response rather than debugging only the missing GET or POST. Cross-origin access generally requires appropriate server responses; changing page code alone may not resolve it.
For requests that remain pending or time out, open the Timing view. It can help distinguish time spent waiting to connect from time spent waiting for the server’s first response or downloading the result. Timing labels differ across browsers, and a single slow request does not establish a lasting performance problem. Repeat the action and compare similar requests before drawing conclusions. You can temporarily disable cache in developer tools to check whether a cached response is masking the behavior, then turn that setting off when you finish.
Record a small, safe debugging summary
Before making changes, write down what you observed: the action you took, the request method and path, the status or browser error, the response type, and whether the failure repeats. Then choose one next check. A wrong path calls for checking URL construction and routes; a rejected request calls for checking the submitted data and server response; a missing response calls for checking connectivity and browser errors.
If you share a screenshot or exported network log, remove or redact cookies, authorization headers, personal data, and sensitive query parameters first. The Network panel can capture information needed to access an account. A concise report with the relevant request details and sensitive values removed is more useful than a screenshot of the entire panel—and safer to share.
