Browser Monitoring: Three Products, One Phrase
Browser monitoring means real user data, a scripted headless browser, or staff surveillance. Here is how to tell which one a vendor is selling you.
Browser monitoring means three unrelated things, and vendors selling all three use the same two words. One watches real visitors from inside your page. One drives a headless browser through your site on a schedule. One reports which websites your staff opened at work. Picking the wrong one wastes a quarter.
What is browser monitoring?
The phrase covers any technique that measures a web session from the browser rather than from the server. Beyond that shared idea the three products diverge completely, in what they install, what they can see and who buys them. Google's own answer box lists all three and then asks which you meant, which is a fair summary of the confusion.
| Sense | What gets installed | What it sees | Who buys it |
|---|---|---|---|
| Real user monitoring | A JavaScript agent in your pages | Live visitors, script errors, device and geography | Front-end and performance teams |
| Synthetic browser checks | Nothing, a vendor runs the browser | One scripted journey, from chosen locations, on a schedule | Reliability and operations teams |
| Workplace monitoring | An extension or endpoint agent on staff machines | Sites visited, SaaS usage, data transfers | IT and security teams |
If you arrived here after reading about employees and browsing history, the third row is your topic and nothing else on this page applies.
Real user monitoring: the agent in your page
New Relic's browser monitoring product is this sense of the phrase. A small script loads with your page, times the navigation, catches JavaScript exceptions, and reports Core Web Vitals back to a collector. New Relic's own documentation describes it as visibility into real users' experiences, which is accurate and also the limit of it.
Two properties follow from that design. You see every device, network and browser version your audience actually uses, which no probe fleet can simulate. You also see nothing at all when traffic is zero, so an outage at 4am is invisible until someone arrives to experience it.
Cost lands in two places: a script in the critical path of every page load, and a per-pageview bill that grows with success.
Synthetic browser monitoring: the vendor's browser
Here a hosted runner loads your page in Chrome or Edge, executes the scripts, records a waterfall per resource and takes a screenshot. Uptrends calls these Full Page Checks, Dynatrace calls them browser monitors, and the mechanism is the same. Nothing is installed on your side.
This tier catches what a plain request cannot: a broken front-end build, a third-party widget that started throwing, a checkout that fails only after the second click. It is also the most expensive check per run and the most fragile. Scripts break when your own markup changes, so they need maintenance on every release.
We prefer one well-kept journey over a dozen neglected ones. A flaky script teaches a team to ignore alerts faster than almost anything else, and that habit is expensive to unlearn. The ladder this rung sits on is laid out in our piece on synthetic monitoring.
Do you actually need a real browser?
Often not, and the test is simple. Ask what breaks in a way an HTTP request would not notice. If the answer is a rendering bug, a client-side route or a payment widget, you need a browser. If the answer is a dead origin, an expired certificate, a bad DNS record or a 500 from your API, you do not.
A request-level check with a content assertion covers the second list at a tiny fraction of the cost. It fetches the page, then fails when an expected string is missing, which catches an error page that still returns 200. That approach is covered in detail under keyword monitoring, and the assertion fields live in the API reference.
Run that check from more than one of the six probe regions available as of September 2026, and a regional routing fault stops looking like a global outage. There is a genuine gap in this approach. An external probe fetches your HTML without executing it, so a page that renders entirely in JavaScript needs either a browser-based check or a server-rendered health route to assert against.
Common mistakes
Buying real user monitoring to detect downtime. It measures the people who arrived. Nobody arrives during an outage, so the graph goes quiet rather than red, and quiet looks like a slow night.
Scripting a browser journey before the basics exist. Certificate expiry and DNS drift cause more incidents than checkout bugs do, and both are caught by a request that costs almost nothing to run.
Confusing the surveillance sense with the performance sense. They share a search term and nothing else. Tools that log employee browsing report on people, not on availability.
Sort the three meanings first and the tooling decision gets much easier. Most teams need a cheap request-level check on every public page, plus one scripted journey through whatever produces revenue. Leave real user data until traffic is heavy enough for it to say something. Browser monitoring earns its price at the top of that list and rarely at the bottom. Put the request-level layer in place today on the free plan.
FAQ
It is any technique that measures a web session from the browser rather than the server. In practice the phrase covers three separate products: a JavaScript agent reporting on real visitors, a hosted headless browser running a scripted journey on a schedule, and endpoint software that logs which sites staff visit at work.
On a work machine, look at installed extensions and managed policies, which most browsers list on an internal settings page. Corporate monitoring usually arrives as a managed extension or an endpoint agent rather than something hidden. This is a device management question, and it has nothing to do with the website performance sense of the term.
Start with a scheduled request that asserts on the status code and on a string that only appears when the page rendered correctly. That catches dead origins, expired certificates, DNS drift and error pages returning 200. Add a scripted browser run later, and only for a journey whose failure would cost real money.
Free tiers differ mostly in check interval and monitor count rather than in features. Uptime Room's free plan covers 10 monitors at a one-minute interval with two-region confirmation as of September 2026. Uptime Kuma is the usual self-hosted answer if you would rather run the checker yourself.
A browser check is one kind of synthetic monitoring, the most expensive kind. Synthetic covers every manufactured check, from a single HTTP request through API transactions up to a scripted browser journey. Real user monitoring is the opposite idea, since it records traffic you did not generate.
Related reading
- Synthetic Monitoring: The Three Rungs Explained - Synthetic monitoring generates traffic on a schedule so failures surface at 3 am with no users online. Here are its three tiers and what each one costs.
- Keyword Monitoring: Catch Broken Pages Returning 200 - Keyword monitoring checks that a phrase is still in your HTML, so you catch the broken page that keeps answering with a healthy 200 status.