Error Monitoring
Definition
Error monitoring is the practice of capturing failures as they happen and putting them somewhere a person will actually look. On a static site the failures fall into a few groups. There are client-side JavaScript failures, which show up as a console error in the visitor's browser and stop everything after them from running. There are missing resources — a script, stylesheet, font or image requested at a path that no longer exists — which appear as 404s in the request log and as blank or unstyled regions on screen. There are failing calls to third parties, such as an embed or an analytics endpoint being refused or blocked. And there are content errors, like a download that returns the wrong file. All of this is separate from uptime checking, because a site can be perfectly available and still broken for every visitor using it.
Why It Matters
Without monitoring you learn about errors from whoever bothers to tell you, and most people do not bother — they leave. A single JavaScript failure early in a page can stop a gallery loading, a menu opening or a form submitting, on every browser that reaches the same code path. The gap between a visitor hitting that and you hearing about it is typically weeks. Error monitoring closes it to minutes, and it is the half of real user monitoring that cares about correctness rather than speed.
How It Works
Client-side collection hangs off two browser hooks: an error event handler on window for uncaught exceptions, and an unhandledrejection handler for promises that fail with nobody catching them. Each captured error carries a message, a source file, a line and column, a stack trace and the user agent; if the JavaScript was minified, a source map is what turns those coordinates back into something readable. The handler posts a small payload to a collection endpoint, normally through sendBeacon so the report survives the page being closed. On the server side, the other input is the request log filtered by HTTP status code — a sudden run of 404s on one path is almost always a rename that missed a reference. Both streams need grouping and rate limiting, since one bad deployment can generate thousands of identical reports, and both need filtering for noise from browser extensions injecting scripts into pages that are otherwise fine.
Real-World Example
An agency ships an interactive pricing calculator to rates-demo.99helpers.site. It works on their machines and fails silently for roughly one visitor in nine, all on older Safari versions, because of a syntax those browsers do not support — the script halts at the first line and the calculator renders as an empty box. A handler reporting window errors surfaces sixty near-identical reports in two days with the browser version attached. The fix takes ten minutes; without the reports nobody would have known, because a visitor who sees an empty box simply closes the tab.
Common Mistakes
- ✕Watching uptime and calling it monitoring — a page that returns 200 with a broken script is available and useless at the same time
- ✕Sending every captured error to an inbox with no grouping — one bad deploy produces thousands of identical messages and the alerts stop being read
- ✕Shipping minified JavaScript with no source map — the reports then arrive as a column number in one unreadable line, which tells you a failure happened and nothing more
Related Terms
Real User Monitoring
Measuring speed and failures from inside the browsers of actual visitors, as they use the site. Usually shortened to RUM.
Broken Link
A link that points at a page or file which is no longer there, so the visitor gets an error instead of the thing they clicked for. Most of the time the server answers with a 404.
Console Error
A console error is a message the browser writes when something on the page fails — a script throwing, a file that would not load, a request the browser refused. It is the first place to look when a page misbehaves.
HTTP Status Code
An HTTP status code is the three-digit number a server returns at the head of every response, saying what happened to the request. It is the first thing on the first line — a 200 means here is the file, a 404 means there is nothing at that address.
Access Log
A line-by-line record of the requests a server has answered — who asked, for what, when, and what came back. It records visitors, not account activity.
Put a file online in seconds
Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.
Host a file free →