Real user monitoring and session replay for the browser, with Core Web Vitals attributed to the element that caused them, and the backend trace the click actually triggered, in the same waterfall.
logfire.configure({
traceUrl: LOGFIRE_TRACE_URL,
serviceName: 'browser',
rum: { webVitals: true },
sessionReplay: {
load: () => import('@pydantic/logfire-session-replay'),
replayUrl: '/api/logfire-replay',
},
})Frontend observability is measuring what your application actually did in someone's browser: how long the page took to become useful, how it responded when they interacted, what broke, and what the app was doing at the time.
Real user monitoring is the same thing under an older name, emphasizing that the numbers come from real sessions rather than a synthetic test running on a schedule. Both terms describe this page.
A page-level LCP of 4.1s tells you there is a problem. It does not tell you that the problem is one hero image, or that the button people actually press is the slowest thing on the page.
LCP, INP and CLS reported as distributions rather than a single average, each attributed down to the DOM selector responsible. A page-level LCP of 4.1s tells you there is a problem; knowing which element is dragging it, and how often that element is the one at fault across all your sessions, tells you what to change.
Scrub the recording, change speed, skip idle time, and read the Navigation, Network and Console tabs alongside it. The point is not watching users, it is reconstructing the twenty seconds before a bug report so you stop asking people to remember what they clicked.
Trace context propagates from the browser into your API, so the browser span and the server work it caused belong to one trace. Open the correlated traces from a replay, or go the other way and jump from a browser span in Live view straight to that moment in the recording. This is the connection a frontend-only tool cannot make.
A frontend exception arrives with the trace it belongs to, so you get the stack, the requests around it, and the recording of what the person was doing. Identical exceptions group into issues, so a new failure mode is one entry rather than a spike in a chart.
Text and input values are masked before anything leaves the browser, and console capture is off, both by default. You narrow further with selectors once you have decided what is safe to record, rather than discovering afterwards that a recording captured something it should not have.
Browser spans land in the same place as your backend spans, your logs and your metrics, and answer to the same SQL. 'p75 LCP by page for signed-in users last week' is a query rather than a feature request, and it can join to anything else you record.
A frontend-only tool can show you that a button felt slow. It cannot tell you the request behind it spent 1.4 seconds in a database query, because it has never seen your database.
Trace context propagates out of the browser and into your API, so the browser span and the server work it caused are one trace.
From a replay you open the correlated traces; from a browser span in Live view you jump to that moment in the recording. Slow page, slow
endpoint and slow
SELECT stop being three investigations.
And because it is all one store, the frontend question and the backend question are written the same way:
select
attributes->>'logfire.page.url.path' as page,
approx_percentile_cont(
cast(attributes->>'web_vital.value' as double), 0.75
) as p75_ms,
count(*) as measurements
from records
where attributes->>'web_vital.name' = 'LCP'
and start_timestamp > now() - interval '7 days'
group by page
order by p75_ms desc;Privacy is the first objection to any recording product, and it deserves a better answer than a paragraph about how seriously we take it. The defaults mask all text and all input values, block media, strip query strings, and leave console capture off.
That means the default recording captures structure and interaction rather than content. You opt things back in deliberately:
sessionReplay: {
load: () => import('@pydantic/logfire-session-replay'),
replayUrl: '/api/logfire-replay',
// On by default: text and input values are masked
// before anything leaves the browser.
maskAllText: true,
maskAllInputs: true,
// Narrow it further, per surface.
maskTextSelector: '[data-sensitive]',
blockSelector: 'iframe, video',
captureConsole: false,
}The direction matters more than the list. A product where you have to remember to mask the credit-card field is one incident away from a bad day; a product where you have to remember to widen the mask is not.
This is browser RUM. There is no mobile SDK today, so iOS and Android sessions live somewhere else for now.
The rest is a deliberate trade. Sessions are reported by page and by country, and browser and device come off the user agent rather than arriving as structured dimensions: there is no pre-built geographic map, device split or unique-user count. What there is instead is every recorded field sitting in the same table as your traces, so the breakdown you want is a query you write today rather than a request you file against a roadmap.
Frontend observability is measuring what your application actually did in someone's browser: how long the page took to become useful, how it responded when they interacted with it, what errors they hit, and what the app was doing at the time. It is the same idea as backend tracing applied to the half of the request that happens on a device you do not control.
They are the same thing under two names. Real user monitoring, or RUM, is the older industry term and emphasises that the measurements come from real sessions rather than from a synthetic test running on a schedule. Frontend observability is the newer term and the one people search for. This page covers both.
LCP, INP and CLS, each attributed to the element responsible rather than reported as a page-level number alone. The browser SDK emits more than that, so other timings are present as spans you can query, but the built-in Core Web Vitals views cover those three.
Yes, and it is the main reason to use Logfire here rather than a frontend-only tool. Trace context propagates from the browser into your API, so a browser span and the server work it caused are part of one trace. From a replay you can open the correlated traces, and from a browser span in Live view you can jump to the moment in the recording.
All text and all input values are masked by default, before anything leaves the browser, and console capture is off. That means the default configuration records structure and interaction rather than content, and you opt specific elements back in once you have decided what is safe to see. The defaults are the conservative direction, which is the right way round for a recording product.
No. This is browser RUM. There is no mobile SDK, so if you need iOS and Android session data in the same product, this is not the right fit today. Anything that can send OpenTelemetry can still send traces, but the RUM, Core Web Vitals and replay surfaces described here are browser-only.
Sessions are reported by page and by country, and everything the SDK records is queryable with SQL like any other span, so custom breakdowns are a GROUP BY away. Worth setting expectations on what is not built in: there is no geographic map, no device or mobile-versus-desktop split, and no session or unique-user counting. Browser and device are derived by matching the raw user agent rather than exposed as structured dimensions.
Get started with 10 million free spans, logs, and metrics per month. No credit card required.