How to use browser developer tools to see failed requests
A request can fail even when the browser window looks normal. The document may appear, but an image, script, font, API call, or stylesheet never arrives. Browser developer tools expose those exchanges through the Network panel, showing the URL, response status, timing, and sometimes the reason the browser rejected a connection. This makes failed-request inspection a practical way to separate a broken webpage from a local network problem.
The exact menus differ between Chrome, Edge, Firefox, and Safari, but the workflow is consistent: open developer tools, select Network, reload, and examine entries marked as failed. A red row is evidence, not a complete diagnosis. The same display can represent DNS trouble, a refused connection, a timeout, a blocked cross-origin response, or an HTTP error returned by the server.
Australian connections add useful context. Many homes use NBN services over fibre to the premises, fibre to the node, hybrid fibre coaxial, or fixed wireless, while mobile hotspots and regional cellular coverage remain common. A page can look complete yet lose requests when a fixed-wireless signal drops, a train journey takes a hotspot out of range, or a network filters a domain. In Melbourne or Sydney, café, library, or airport Wi-Fi may present a captive portal that leaves requests pending until its login completes.
Before digging through headers, retry the page, confirm that ordinary sites load, and try another device or network where practical. If those checks do not clarify the fault, this basic troubleshooting page provides a concise set of connectivity checks. Then use browser evidence to identify which layer needs attention rather than repeatedly refreshing and hoping.
Set up a clean network trace
Open developer tools with F12 on Windows and Linux, Ctrl+Shift+I in Chrome or Edge, or Command+Option+I on macOS. In Firefox, use the menu beside the address bar if needed. Choose Network, clear existing entries, and reload the page so old requests cannot be mistaken for the current attempt.
Enable Preserve log to compare a navigation with redirects or background calls. Disable cache only for diagnosis; leave it off afterwards because the normal cached experience is what most visitors receive. Filter by Doc for the main page, Fetch/XHR for API calls, or Img, CSS, JS, Font, and Media for assets. Mobile emulation is useful when a responsive layout triggers a different set of calls.
Recognise what actually failed
Start with the request name, status, and Type. A line marked failed with ERR_NAME_NOT_RESOLVED points towards name resolution; ERR_CONNECTION_REFUSED usually means the server did not accept the connection; ERR_CONNECTION_TIMED_OUT suggests no response arrived. Browser-generated errors differ from HTTP codes because the server may never have received the request.
An HTTP response means the request reached an HTTP server. A 404 indicates a missing resource or path, 403 signals refusal by server policy or authorisation, 401 means valid credentials are still required, and 429 indicates rate limiting. Codes from 500 to 599 report server or gateway failures. These responses are not interchangeable with a transport failure.
Read the Timing breakdown after identifying the failed row. DNS lookup, connection, TLS, request, and response phases reveal where time was spent. Headers and Initiator show the response details and the page element or script that created the request. The Console may add CORS, mixed-content, CSP, or service-worker messages that explain a failure hidden behind a generic browser error. In Australian support chats, “the server’s having a whack” is common shorthand for a crash, but the trace shows whether the server actually failed or the request never arrived.
Match signals to likely causes
Use the visible signal to narrow the boundary before changing settings:
| Signal | What it usually means | Best next check |
|---|---|---|
| ERR_NAME_NOT_RESOLVED | DNS could not map the hostname to an address | Check the hostname, DNS service, and nameservers |
| ERR_CONNECTION_REFUSED | The destination rejected the connection | Confirm the port, service, and that the host is running |
| ERR_CONNECTION_TIMED_OUT | No usable response arrived within the limit | Compare another network and inspect firewall or routing behaviour |
| 404 | The server received the path but the resource was absent | Verify the URL, build output, and deployment paths |
| 401 or 403 | Authentication or authorisation prevented access | Check credentials, permissions, and server policy |
| 429 | The server is throttling requests | Slow down, back off, and inspect rate-limit headers |
| 500–599 | The application or an upstream gateway failed | Review server and gateway logs |
| CORS, CSP, or mixed-content error | The browser blocked the request or restricted access to its response | Read the Console and inspect the relevant security headers |
A 304 or 200 from cache is a successful result, not a failure. Likewise, a 204 means the request succeeded with no response body. Treat redirects as steps in a chain: inspect each Location header and watch for loops, HTTPS-to-HTTP downgrades, or a redirect into a blocked cross-origin URL.
Trace DNS, redirects, and timing
A DNS error usually names the failing stage clearly, but repeated timeouts may come from DNS, routing, filtering, or an overloaded destination. Test the hostname with a second device on a different connection. Restarting the browser, router, or hotspot can clear stale resolver information, while switching between mobile data and fixed broadband can reveal an ISP-specific block.
For an Australian business using a .com.au domain, remember that the namespace, registrar, authoritative nameservers, and hosting can sit with different providers. Check the domain registration and DNS records before assuming the web application is faulty. Redirect chains can also consume browser limits; follow each Location value and confirm that every hop uses a supported scheme and certificate.
Separate cache, workers, and third parties
Cache and service workers can change the result between visits. A failed request may be an old cached response, while an active service worker may intercept a URL and serve stale content or throw its own error. Use the Application panel to inspect registered workers, and compare a normal window with a private window or a freshly created browser profile. If only one profile fails, suspect local storage, extensions, cookies, or the worker rather than the server.
Third-party resources create another boundary. Compare the main document with embedded content such as the classic slots page and inspect each Initiator chain instead of assuming every failed row came from the site being tested. Advertisements, trackers, maps, and identity widgets can all be blocked independently. A first-party API failure usually has a same-site initiator; a third-party failure points to the embedded provider.
Reproduce and share evidence safely
After capturing the failure, reproduce it in a controlled way. Reload once with cache disabled, note whether it happens on every attempt, and retry the exact URL from the Console when the endpoint is known. For example, fetch("/api/status") can confirm whether JavaScript receives the expected response, but an opaque CORS response does not by itself prove the server is down. Compare browser results with a simple request from a trusted terminal tool, changing only one variable at a time.
Export a HAR file when another person needs to reproduce the problem, but inspect it first. HAR archives may contain cookies, authorisation headers, query strings, form values, and personal details. Remove credentials and identifying data before sharing. Australian teams should also consider whether the capture falls under the Privacy Act 1988 and the Australian Privacy Principles, particularly when a request contains customer, health, or account information.
Put the fix into action
Fix the layer identified by the evidence: correct a misspelt host or deployment path, renew an expired certificate, restore a server process, adjust a firewall rule, or ask the hosting provider to investigate a gateway error. If a CORS or Content Security Policy rule blocks a valid response, change the server configuration rather than disabling browser security. Clear the relevant cache or unregister a faulty service worker only after confirming it is the source.
Record the browser, operating system, device, network type, reproduction steps, status, and sanitised trace. A precise timestamp helps compare reports from different Australian cities, while a clean HAR gives support staff a reproducible starting point. Confirm the repair with a fresh reload and a private window, then restore normal caching and close developer tools.
Use the failed request as the next action item: open the Network panel, reproduce the fault, capture one decisive trace, and share only the sanitised evidence with the person or provider responsible. That sequence turns a vague report that the page will not load into a specific request that can be fixed and verified.