BRUM Overview
Browser Real User Monitoring (BRUM) watches how real visitors use your website. A small piece of code — the agent — is added to your site once. From then on, every visitor's browser quietly reports back to CodeXray: which page they loaded, how long it took to appear, any JavaScript errors they hit, console messages, and the network calls the page made.
CodeXray turns those reports into screens: which applications are being used, how fast their pages are, what's breaking, who's affected, and what a single failing page load actually did.
As someone who owns a website used by real customers, I want to see what those customers actually experienced — how slow each page was, what errors they hit, and how many were affected — so that I can fix the things hurting real people, instead of guessing from server-side numbers that look fine.
You'll find it under EUM → BRUM in the left navigation.
Synthetic Monitoring is CodeXray driving a browser itself on a schedule. BRUM is CodeXray watching real visitors use your real website. They're companions — synthetic catches problems before anyone hits them; BRUM shows what your actual users are living through.
How it works
| Step | What happens |
|---|---|
| 1. The agent is installed | A developer adds the package to the website once, with the CodeXray address and the application name. See Install the BRUM Agent. |
| 2. Real visitors use the site | Nobody has to do anything special — ordinary visits produce the data. |
| 3. The browser sends reports | Small reports ("beacons") are sent as pages load and as errors happen, roughly every second. |
| 4. Screens fill in | The Applications list, then per-application Overview, Performance, Errors, Logs, and Traces. |
Key terms
These words mean exactly one thing everywhere in BRUM. Several look interchangeable but aren't — it's worth reading this before you read the numbers.
| Term | Plain meaning |
|---|---|
| Application | One website reporting data, by the name the agent was configured with. |
| Agent | The package inside the website that sends the reports. |
| Beacon | One report from a browser — a page load, an error, a log line, or a trace. |
| Total Requests | Every page load, refreshes included. |
| Page Views | Distinct person + page combinations. Reloading the same page 10 times is 1 page view, not 10. |
| Pages | How many different pages got any traffic in the selected time range. |
| Users | Distinct browsers. The same person on a laptop and a phone counts as 2. |
| Impacted Users | Users who hit at least one error. |
| Error Rate | The share of page views that had an error, from 0 to 100%. |
| Error categories | Who caught the error: js (code crashed), ajax/api (a network call failed), promise, vue, resource, unknown. |
| JS Error % / API Error % | Share of that application's errors in that category. |
| Load time / TTFB / FCP / LCP | How long the page took overall; how long the server took to answer; how quickly the first, then the biggest, content appeared. |
| Trace / Span | A trace is one thing the visitor did (a page load, a click, a network call); a span is one step inside it. One page load produces many spans. |
| Severity | How serious a log line is: error, warning, info, debug. |
Application health
Each application is rated at a glance:
| Health | Meaning |
|---|---|
| GOOD | The application is in good shape. |
| MODERATE | Some degradation — worth a look. |
| POOR | Significant errors or slowness affecting users. |
The health word always agrees with the healthy-percentage shown beside it.
How the time range works
Card numbers, charts, and tables all follow the time picker. Next to many cards, a ▲▼ arrow compares one window against the one before — always hour-against-hour, capped at one hour.
| You select | The arrow compares |
|---|---|
| 15 minutes | these 15 minutes vs the previous 15 minutes |
| 1 hour | this hour vs the hour before |
| 24 hours | this hour vs the hour before |
| 7 days | this hour vs the hour before |
Hovering an arrow shows which two windows are being compared. When the earlier window had no traffic, no arrow is shown.
BRUM reflects real visits, so its numbers change as people use your site. Allow about a minute between using the site and expecting the screens to move, then refresh.
What BRUM does not do
- MRUM (mobile app monitoring) — a separate item in the left nav.
- Frameworks other than React and Vue — not supported today.
- Alerting / notifications based on BRUM data.
- Session replay / video of a user's session.
- Following a browser trace into backend services — BRUM is browser-side for now.
Next steps
- Install the BRUM Agent — add BRUM to a React or Vue app
- Applications & Overview — find your app and read its health
- Performance & Page Details — page speed by browser, device, and page
- Errors, Logs & Traces — from an error to a single occurrence and its trace