Every in-page monitoring tool has the same blind spot, and it is not a bug in any of them. Error trackers, analytics, session recorders, the browser extension I work on: all of them are JavaScript that runs on your page.
So none of them can tell you anything about the times your page did not run.
The failures that leave no trace in the browser
Think about what the user sees in each of these:
- DNS does not resolve.
DNS_PROBE_FINISHED_NXDOMAIN. - The connection is refused or times out.
ERR_CONNECTION_REFUSED. - The certificate does not validate.
NET::ERR_CERT_AUTHORITY_INVALID, and a full-page warning. - The CDN returns a 502 from its own error page, not yours.
- A corporate proxy or a DNS filter blocks the domain outright.
In every one of them the browser shows its own page. That page is not your site. Your HTML never parsed, your bundle never downloaded, your snippet never initialised, and there is no place for a window.onerror handler to exist, let alone fire.
Which means your error tracker records nothing. Not a zero. Nothing: no event, no session, no user. The dashboard does not go red. It goes quiet in a way that is indistinguishable from everybody having a lovely time.
The half that surprises people is the server side
The instinct is that at least the server knows. Often it does not.
A DNS failure never produces a connection, so nothing reaches you at all. A blocked domain is the same. A refused connection never becomes a request. A TLS handshake that fails never becomes an HTTP request either, so it does not appear in your application's access log, which only ever sees requests that got that far. Depending on how the terminating proxy is configured, a handshake failure may appear in its error log, which is a different file that most teams read only when they already suspect something.
So for this class of failure you have two instruments, and both are pointed the wrong way:
in-page monitoring → requires your page to run → it did not
application logs → require a completed request → there was none
The overlap of those two blind spots is the set of users who could not reach you. They are, by definition, the users least represented in every number you have.
This is survivorship bias with a build step
Your metrics describe the people who got in. Uptime checks from a monitoring service describe a machine in a datacentre that has clean DNS, no proxy, a correct clock and a fresh certificate store. Both are useful. Neither is evidence about the person whose employer's MITM proxy rejected your chain this morning.
That gap has a shape worth remembering: the failures that are invisible to you are disproportionately the ones that are specific to the user rather than to your server. A clock that is a year out. A resolver that is being filtered. A network that intercepts TLS. Your server is fine for everyone else, your instruments agree, and one person is locked out with a red screen.
What actually finds them
Three things, none of which is your error tracker.
Check from outside, from more than one place. Not a browser you have used before: one that has never fetched your intermediate certificate, on a network that is not yours. External checkers exist precisely because your own machine is a contaminated instrument.
Read the layer below the application. Handshake failures, connection resets and blocked requests live in the proxy or load balancer logs, not the app's. If you have never looked at that file, you do not know whether it is empty.
Take the report seriously when it arrives. This is the awkward one. For this class of failure the only signal that exists is a human being telling you, and they will tell you badly, because there is nothing for them to copy. No console, no network tab, no error id. Just a red page and a sentence.
That is the part worth internalising. Most of the time, "the report is vague" is a process problem you can fix by asking for more. Here it is a physical constraint: the browser refused before anything of yours existed, so there is nothing to collect, and the vague sentence is the whole of the evidence that will ever exist.
Which changes what to do with it. Not "please reproduce it with the console open". Instead: what exact words were on the screen, what time does their device say it is, does it happen on mobile data. Three questions that work precisely because they do not assume your page ever loaded.
Your dashboards will still be green while you ask them.
Top comments (0)