Network errors
Requests that failed in the browser — the errors your server logs never see.
Logs & Errors → Network Errors shows requests that failed in the browser.
Why they need their own page
A request blocked by CORS, cancelled by a navigation, or dropped by a flaky mobile connection never reaches your server. It is not in your access log, not in your error log, and not in your error rate.
From the server, the user simply did not arrive.
What is captured
| URL and method | Normalised, so ids do not fragment the group |
| Failure kind | Timeout, DNS, CORS, TLS, refused, aborted |
| Status | Where there was one |
| Country and connection | Where the user was, and on what |
| Timing | How long before it failed |
The kinds worth recognising
| Kind | Usual cause |
|---|---|
| CORS | A misconfigured header. Affects every user on that path, not a subset |
| Timeout | Slow origin, or a mobile network. Check the country breakdown |
| Aborted | Often just navigation. A rise is still worth a look |
| TLS | Certificate problem, or an old client |
| DNS | A record change that has not propagated, or a resolver problem |
CORS failures are the most under-diagnosed error in most deployments. They are invisible server-side, they affect 100% of requests to that path, and the browser console message is deliberately vague for security reasons. This page is often the only place they are visible at all.
Getting the data
The web-monitor SDK reports them. There is no other source — by definition, these requests did not reach anything of yours.
Alerting
Rules on volume and on the appearance of a new kind for a given host.
A new CORS failure on an existing endpoint is almost always a deploy that changed a header, and it is worth paging on immediately.
Where this behaviour lives: frontend/src/app/errors/network/. If the code and this page disagree, the code is right — please fix the page.
Part of Logs and errors — What the software said about itself, and what was unusual about it.